mgutt

I know it's an old post, but I need to ask as this is the only official statement regarding SSDs in the array. Why did you wrote "should"? And why this sentence: This is confusing as it is not possible to TRIM SSDs in the array, why should they need to support any TRIM feature? Regarding my own experience (I build several SSD only Unraid servers for different customers), there is absolutely no reason, not to use SSDs in the array. @JorgeB seems to be the only person who had bad experiences because of an defective Kingston V300 which changed data while his server was shutdown (I mean an SSD which changes data while it's powerless can't be ok and it has clearly nothing to do with TRIM or not to TRIM). And until now he never heard about other people with similar problems. So why are SSDs in the array still not officially "approved"? I think its time to take away the fear.

Ich denke er meint vor allem die verschiedenen Befehle.

Die QVO ist gekommen und gerade fand ich noch eine für den Preis. Da konnte ich auch nicht nein sagen. Damit hätte ich an großen SSDs immerhin schon 2x 4TB und 2x 8TB. Also 24TB verteilt auf 4 SATA Buchsen. Das blöde ist, dass ich mit einer SATA Erweiterungskarte mindestens 2W zusätzlich hätte und eine 18TB HDD zieht im Standby 1.21W: https://forums.unraid.net/topic/103012-wo-gibt-es-günstige-hdd-ssd/?do=findComment&comment=967189 Um also effizienter zu sein, darf ich eigentlich nur 8TB SSDs einsetzen. Gar nicht so einfach HDDs loszuwerden 🤪

Laut Recherche in der Kommandozeile mc eingeben und dann den Midnight Commander nutzen. Der soll auch packen / entpacken können.

Sadly, yes.

Hab ich jetzt auch ausprobiert. Dann will er alles transcodieren und nichts spielt. Ich werde das mal bei mir zu Hause mit dem Samsung Q9FN testen. Dann über Handy als WLAN Hotspot.

Mehr macht der Mover nicht. Er kann nur zwischen Cache und Array Dateien hin und her bewegen. Nicht zwischen Disks verteilen.

Es ist eher ein "oder", denn ECC geht beim C246 sogar mit einem 50 € Pentium Gold.

Die GUI hat Rootrechte. Portfreigabe ist zu riskant

Seit wann gibt es Support auf Datenintegrität? Ich kann mich auch nicht erinnern, dass Limetech bei kaputten BTRFS RAIDs den Kopf hinhält. Und das hatten wir ja nun schon oft genug. Wie genau darf man das denn interpretieren, dass SSDs dem Array zugewiesen werden können, Trim deswegen deaktiviert wurde und es keine Warnung gibt? Squid, der nicht Limetech ist, warnt übrigens über CFP, weil JorgeB mit der, ich sage jetzt bewusst, defekten V300 das Problem hatte. Andere Fälle kennt der auch nicht.

Nein kann es nicht, weil man SSDs im Array nicht trimmen kann. Limetech mountet die SSDs so, dass das nicht möglich ist. Daher ist das ja so sinnfrei davor zu warnen.

Ich habe wie gesagt die Begrenzung der Bitrate über das Internet auf 25 Mbit/s angehoben. Jetzt können mehr Inhalte per Direct Play abgespielt werden: Sobald aber Transcoding ins Spiel kommt, bricht die Verbindung ab: Ich habe daraufhin auch bei den Transcoding-Optionen des Servers zwischen Automatisch und höchste Qualität herumgespielt und die Pufferzeit geändert und beim TV auch auf H.264 Level 4.1 begrenzt, aber nichts hilft Auch mal im TV auf 4 Mbit/s reduziert, aber das bricht ebenfalls ab:

Dann muss ich mich irgendwie falsch ausdrücken. Also ich fasse noch mal alles Wichtige zusammen: Offizielle Aussage von Limetech: https://forums.unraid.net/topic/53433-ssds-as-array-drives-question/?tab=comments#comment-522482 übersetzt: Ja sie haben "sollten" geschrieben. Also schauen wir mal welche User Probleme mit SSDs im Array haben. Bis heute kenne ich nur eine Meldung. Und die ist von JorgeB: https://forums.unraid.net/topic/82620-all-ssd-unraid-pool/?tab=comments#comment-767384 übersetzt: Die Kingston V300 ist übrigens eine SSD, die bekannt für Freezes und RAID-Problemen ist. Ich habe ihn dann mal gefragt ob er noch andere Fälle kennt und er macht wohlgemerkt seit vielen Jahren hier im Forum Support für Unraid: https://forums.unraid.net/topic/47266-plugin-ca-fix-common-problems/?do=findComment&comment=947567 Not that I'm aware of. Er kennt also keinen anderen Fall und bei seinem Erlebnis mit der Kingston V300 wurde die Parität nicht mal im Betrieb verändert, sondern als sie vom Strom getrennt wurde, was logischerweise nichts mit Trim oder GC zu tun haben kann. Vielleicht sollten wir wegen möglicher Korruption auch vor SMR HDDs im Array warnen. Die nutzen nämlich auch alle GC.

Informiere dich was Trim macht und was die Garbage Collection macht. Wenn die GC Daten verändern würde, würde das ja heißen, dass sie einfach deine Dateien ändert. Das glaubst du dich nicht ernsthaft? Befrei dich mal vom Gedanken, dass eine SSD weiß welche Sektoren zu welcher Datei gehören. Das weiß sie nämlich nicht (deswegen gibt es ja überhaupt Trim). Es gibt zig verschiedene Dateisysteme, mit unterschiedlichen Versionen und RAID Varianten. Die kann eine SSD nicht kennen. Die kennt nur Sektoren. Erst durch Trim erfährt die SSD welche Sektoren nicht mehr verwendet werden. Und erhält sie diesen Trim Befehl, dann verändert sie diese Sektoren in Nullen (RZAT) oder lässt die Daten wie sie sind (DZAT). In beiden Fällen werden die Pages für GC zum Aufräumen freigegeben. Allerdings steht bei DZAT "shall" im Standard. Es kann also leider von Hersteller zu Hersteller unterschiedlich sein, was dann wirklich passiert. Außerdem darf man nicht vergessen, dass diese Änderung nur auf dieser einen SSD passiert. Die Parity erfährt davon also nichts und wird nicht angepasst = kaputt. DZAT wäre daher optimal für unRAID, weil die Sektoren nach wie vor die selben Daten zurückliefern = Parität bleibt valide. Aber genau das müsste man wegen dem "shall" je nach SSD erstmal testen. dlandon schlug dagegen vor nur RZAT SSDs zu erlauben, aber genau das resultiert in dem Problem, dass man gar nicht weiß was die SSD nun alles genullt hat (sie gibt ja nicht die geänderten Sektoren zurück). Also wäre man gezwungen die Parity zu reparieren = macht keinen Sinn für unRAID, weil die Parität nach jedem Trim repariert werden müsste. Daher drehte ich mich mit Limetech in dem Punkt im Kreis. Und ich sage nach wie vor, dass DZAT die einzige Lösung ist, aber da müsste man eben mit einer Allowliste an SSDs arbeiten. Oder man lässt eben Trim weg, wie es bereits der Fall ist. Nur dann spreche ich mich ja nicht gegen SSDs aus. Ich mein welchen Sinn hat das. Man kann SSDs im Array zuordnen, es gibt extra die Deaktivierung von Trim, aber eigentlich sind SSDs gar nicht erlaubt. Sorry, aber dann bitte konsequent keine SSDs im Array erlauben.

Tun sie auch nicht. Siehe: https://hub.docker.com/r/linuxserver/plex/tags?page=1&name=Beta

Eine SSD kann intern kein Trim. Und die Garbage Collection verändert keine Daten. Sie fasst Daten nur in andere Pages zusammen um freie Pages zu schaffen. Das Problem ist einzig RZAT und DZAT. Siehe auch hier: https://forums.unraid.net/topic/73110-ssd-array-for-unraid/?do=findComment&comment=923680 Und das ist wie gesagt ausschließlich ein Problem, wenn man Trim ausführt. Ohne Trim geht die Parity nicht kaputt.

Die Jungs bei Limetech haben irgendwann mal eine SSD in der Hand gehabt, die nach einem Trim die Parity kaputt gemacht hat. Danach wurde Trim deaktiviert und parallel gesagt, dass SSDs nicht im Array empfohlen sind. Sie haben also den Workaround geliefert und von der Nutzung abgeraten, was einfach keinen Sinn macht. Es gab bisher auch keine Bemühungen eine Allow- oder Blockliste von trimfähigen SSDs aufzubauen. Es wäre sogar ohne weiteres automatisiert testbar. Stattdessen verweist man auf das müllige BTRFS, was regelmäßig über den Jordan geht, wenn der Server crasht oder der Strom ausfällt. Davon abgesehen habe ich Null davon, wenn ich 5 SSDs im RAID Dauerlauf habe. Das sind ja auch wieder 20W für nothing. Ach ja. Ich habe schon zig SSD only Server gebaut. Allerdings alle mit Enterprise SSDs, die alle problemlos ohne Trim klar kommen. Und mich hat da noch kein Kunde angerufen, dass seine Parity kaputt sei. Ich erwarte bei Samsung und WD allerdings auch keine Probleme bei Consumer SSDs. Mehr dazu, wenn ich es getestet habe.

Die Einstellungen befinden sich in einer XML Datei auf dem Stick. Machst du keine Backups vom Stick? Ist es bereits. Den kaputten Container kann man nicht mehr retten. Aber ich denke die XML ist noch auf dem Stick. Einfach Mal add Container und im Dropdown schauen. Ist da kein Plex dabei? Bzw auf dem Stick schauen:

Ich werde das auch machen, weil für eine SSD als Parity hab ich schlicht keine Kohle (ich bräuchte größer als 18TB). Die SSD im Array liefert schnell (keine Spinup Wartezeit) und effizient die Dateien und beim Schreiben fängt wie gehabt der Cache ab. Auf die SSD im Array packe ich ja keine VM. Und fehlendes Trim ist beim reinen Lesen ja eh Wurst.

Zuerst würde ich ein Backup vom appdata Ordner machen bzw ich hoffe das machst du eh immer. Dann aktiviere die erweiterte Ansicht bei Docker. Taucht da evtl ein toter Container in der Liste auf? Den löschen. Dann einfach neu installieren mit deinen bisherigen Einstellungen. Solange du die selben Pfade / Variablen hinterlegst, wird es da keine Probleme geben.

Das hatte ich bisher getestet Die automatische Bitrate kann die Samsung TV App meine ich nicht. Die Einstellung finde ich jedenfalls nur bei Android Auf dem Server: Ja, laut Plex ist das nicht bei Samsung verfügbar und standardmäßig auch überall deaktiviert: https://support.plex.tv/articles/115007570148-automatically-adjust-quality-when-streaming/ Was mich aus den Logs verwundet sind die 8 MBit/s, woher nimmt der die? only 8000kbps is available Und selbst wenn nun dieses Limit gilt. Soll er eben transcoden. Macht er ja auch. Aber bricht dann eben ab. EDIT: Ich habe es auch noch mal auf einem Android gecheckt. Da kann ich sogar nur maximal 8 Mbit/s auswählen?! Allerdings geht jede einzelne Bitrate problemlos. EDIT: Ok, das macht Sinn. Wenn ich auf dem Server 20 MBit/s einstelle, dann kann der Client maximal 12 Mbit/s auswählen?! Und bei 25 MbIt/s auf dem Server kann der Client max 20 MBIt/s auswählen. Nun gut. Dann sollte er ja jetzt ohne Transcoding mehr abspielen, aber vermutlich trotzdem verkacken sobald es einsetzt. EDIT: Noch was gefunden. Laut Samsung geht bei 1080p max Level 4.1 Evtl teste ich ein kleineres Limit?! Wobei das bei mir zu Hause auch mit dem höheren Level beim Transcoding klappt und ich habe einen Samsung der selben Generation.

Das dürfte eine Art Reset Bug sein, wie es auch manche Grafikkarten haben. Die Karte ist dann quasi aus, wenn die VM herunterfahren wurde und geht dann nicht mehr an, weil sie von der Firmware her so eingestellt ist, dass sie erwartet, dass erstmal der Strom ausgeht. Und durch die Neuinstallation der Treiber triggerst du sie dann vermutlich wieder an. Eventuell hilft es die Karte nach dem VM Shutdown zu löschen und neu einlesen zu lesen oder wie in der zweiten Antwort zu disablen und wieder enablen: https://unix.stackexchange.com/a/245184/101920 Allerdings weiß ich nicht wie das mit VFIO kollidieren könnte.

Müsste man das mal testen: https://github.com/Distrotech/hdparm/blob/master/wiper/wiper.sh Das hat man damals genutzt als es noch kein fstrim gab.

Eingestellt habe ich 4K 10 MBit/s. Der Server erlaubt 12 MBit/s. Und jetzt erklär mir mal warum der nur 8 Mbit/s erlaubt und 1080p in 720p wandelt. Macht irgendwie alles keinen Sinn. Denke ich muss mal mit VPN oder Server vor Ort probieren.

Which cores do you assign? Your CPU has 6 usual and 6 HT cores. You are not allowed to assign HT cores alone. And do not isolote Core 0 and HT 6. The first core pair should be used by Unraid.