mgutt

Was geht denn mit dem MySQL Container einfacher?

There is no "or" in the ATA / ATAPI command set page 82:

Ok, looks like the TRANS_DIR values aren't really paths. Instead these are "switches" to select between three predefined paths. So the solution would be to set TRANS_DIR to /tmp Does Binhex generate an additional subfolder in /tmp if this setting is used?

With RZAT some sectors return 0 although they returned 1 before and so the Unraid parity, which was calculated with the 1, would be now incorrect. So this does not work. Or you must correct the parity in the same turn.

Post deleted

As shown in the screenshot the container path /transcode needs to be linked to the hosts ram disk path. If you press the edit button of the path, what is set as container and what as host path? Take a screenshot of you like.

Ah okay. And what sends the TRIM command? As far I understand fstrim / FITRIM never sends the TRIM ata command. Instead it manually deletes the sectors: https://www.thomas-krenn.com/en/wiki/ATA_Trim_command#Online_or_Batched

Ok, this is the interesting part: As Unraids parity is sector based, we need DRAT. But what sends this ATA command? fstrim calls FITRIM: https://github.com/karelzak/util-linux/blob/master/sys-utils/fstrim.c And as far as I was able to follow the functions called by FITRIM, it only sets the sectors to the status "discard" (it's ext4, but should be similar for XFS) FITRIM: https://code.woboq.org/linux/linux/fs/ext4/ioctl.c.html#991 Last nested function I found: https://code.woboq.org/linux/linux/block/blk-lib.c.html#__blkdev_issue_discard

As far I understand the TRIM process it fully depends on the SSD controller if ti zeros the discarded sectors or not. Is there a way to find out if the SSD controller preserves the discarded sectors or zeros them? And regarding the Parity: What about adding two parity disks and re-buidling the parity1 each odd month and re-buiding the parity2 every even month? By that you have for several hours each month only one parity protection, but the SSD is fully "trimmed".

Ich habe mal recherchiert. fstrim macht nichts anderes als FITRIM auszuführen: https://github.com/karelzak/util-linux/blob/master/sys-utils/fstrim.c * This program uses FITRIM ioctl to discard parts or the whole filesystem * online (mounted). You can specify range (start and length) to be * discarded, or simply discard whole filesystem. FITRIM dagegen ruft ext4_trim_fs auf (XFS wird da mit eigenen Funktionen denke ich drauf aufbauen): https://code.woboq.org/linux/linux/fs/ext4/ioctl.c.html#991 ret = ext4_trim_fs(sb, &range); Das geht dann verschachtelt so weiter bis zu der Funktion "__blkdev_issue_discard", die scheinbar den Discard-Status vom Sektor setzt. Ab dann übernimmt denke ich der SSD-Controller und das ist wohl der Punkt wo man nicht mehr weiß was mit dem Sektor passiert. Also ob er von der SSD genullt wird oder die Daten erhalten bleiben. Da die Unraid-Parität über die Sektoren berechnet wird, kann das diese je nachdem zerstören. Das erklärt auch warum manche kein Problem mit SSDs im Array haben. Die nutzen scheinbar eine SSD wo der Controller die Sektoren nicht einfach nullt. Jetzt müsste man nur wissen welche SSD was macht und ob man das herausfinden kann. Mich würde zB interessieren ob eine Enterprise SSD wie die Micron ION 5210 nutzbar wäre. Wobei natürlich klar ist, dass man die Paritätsdisk niemals trimmen kann, weil da einfach kein Dateisystem hinterlegt ist, was sich trimmen lässt. Allerdings könnte man das in den Griff kriegen, in dem man zwei Paritätsdisks einsetzt und diese im Wechsel zB 1x pro Monat komplett neu erstellen lässt. Dann hätte man für den einen Tag eben nur eine Disk als Ausfallsicherheit (bzw dank SSD ja eher wenige Stunden). Und für das sonstige Array braucht man denke ich eh kein TRIM, weil sonst hätte man die SSD ja gleich als Hot Storage, also als SSD Cache konfiguriert. In BTRFS ist das scheinbar übrigens kein Problem, weil da die Parität des RAID über die Datenblöcke und nicht über die Sektoren berechnet wird. BTRFS ist es also egal was der SSD Controller mit ungenutzten Sektoren macht, da es diese eh nicht für die Berechnung der Parität heranzieht.

@ich777 Wieso geht denn kein Trim? Kann ich eigentlich nicht glauben. Bei der Paritätsdisk vielleicht, aber die restlichen Disks sind ja ganz normale XFS formatierte Disks.

Durch die im Wiki beschriebene erste Methode "For unRAID v6.2 and later", wird die Disk, die du entfernen möchtest, komplett mit Nullen beschrieben, was auch die Parität entsprechend korrigiert. Dadurch ist nach Ausbau der Disk die Parität immer noch korrekt, weil eine Disk komplett mit Nullen das selbe Ergebnis bei der Berechnung der Parität ergibt, wie eine komplett fehlende Disk. Wichtige Dinge dieser Methode sind Die Daten von der zu entfernenden Disk auf andere verschieben / kopieren Die Disk bei allen Shares (include/exclude) entfernen Ob du nun dieses Methode anwendest, also die zu entfernende Disk jetzt mit Nullen beschreibst, hängt nun davon ab ob du: überhaupt eine Parität hast und ob dir die Parität wichtig ist. Die unter "For unRAID v6.0 and 6.1 and possibly 5.0" beschriebene zweite Methode (geht auch in neueren Versionen), setzt dagegen voraus, dass du einen Screenshot/Foto von der Disk-Übersicht machst, die Disk ausbaust und per New Config die Disks wieder so zuordnest wie sie waren, während man das Dropdown der nun fehlenden Disk leer lässt. Ist eine Parität vorhanden, setzt diese Methode noch voraus, dass du "Parity is already valid" nicht auswählst. Nun wird die Parität komplett neu aufgebaut. Bei dieser Methode hat man also in der Zeit keine Parität / Ausfallsicherheit. Eine dritte, nicht beschriebene Methode wäre wie bei der zweiten vorzugehen, aber stattdessen "Parity is already valid" auswählen. Nun startet das Array mit einer falschen Parität. Diese korrigiert man dann mit einem Parity-Check (und mit aktiver "Write corrections to parity" Option). Auf die Art würde die Parität nicht komplett neu erstellt, sondern nur die Teile aktualisiert, die sich geändert haben. Ich könnte mir vorstellen, dass das die schnellste der drei Methoden ist. Zusammenfassung Willst du durchgehend eine valide Parität, dann verwende Methode "For unRAID v6.2 and later". Hast du dagegen gar keine Parität, dann mach nur die wichtigen Dinge und ordne zum Schluss per "New Config" die Disks wie zuvor zu (Screenshot!). Ist dir die Parität nicht so wichtig, dann verwende eine der anderen Methoden nach belieben. Hinweis Per New Config kann man übrigens auch die Disks umzusortieren, allerdings bekommen die dann andere Disk-Nummern und die "include"-Disks bei den Shares stimmen nicht mehr überein. Man müsste also nach der Umsortierung die "include"-Disks der Shares korrigieren und evtl mit dem UnBalance Plugin in der Zwischenzeit falsch abgelegte Daten auf die korrekte Disk zurück verschieben. Zum Schluss müsste man dann natürlich noch einen Parity-Check machen. Habe ich auch schon mal gemacht, weil das schneller ging als die Daten zwischen den Platten zu verschieben, aber das sollte man nur machen, wenn man das Konzept verstanden hat.

Ich würde jetzt erstmal genau in Erfahrung bringen ob es an SATA/HDD, der Cloud oder LAN liegt. Du könntest übrigens auch nur den Upload in die Cloud starten und dann im WebTerminal das ausführen: wget -O "/dev/null" "https://speed.hetzner.de/1GB.bin" Also einfach parallel einen Download ohne Festplatte und eben von einer Quelle, die nichts mit deiner Cloud zu tun hat.

Was ist denn die Quelle und was das Ziel? Immer die selbe HDD? Kannst du es mit zwei verschiedenen HDDs testen, so dass wirklich nur von einer in die Cloud gelesen wird und auf die andere aus der Cloud geschrieben? Oder vielleicht beides auf einer SSD um sogar die Paritätsberechnung außen vor zu lassen? Hast du evtl auch eine andere Cloud zum Testen? Irgendein kostenloser Account mit ein paar GB. Einfach um andere Dinge auszuschließen.

Dann hast du bereits den Inhalt der ZIP-Datei gesehen. Ich wollte die komplette ZIP-Datei haben. Aber klappt ja jetzt. Fürs nächste Mal weißt du ja wie es geht

1.) Die Diagnosedaten erstellt man unter Werkzeuge > Diagnose 2.) Du hast in den SMB Einstellungen "Active Directory" ausgewählt. Warum? Weißt du überhaupt wozu man das braucht? Wenn nein, dann wähle dort "WORKGROUP". Ich denke das wird dein Problem bereits beheben. 3.) Der Name der Workgroup steht ganz unten bei den SMB Einstellungen. Noch unter SMB Extras.

Runterscrollen. Steht unten auf der Seite. Ich kenne die Beta nicht, aber in der Stable wird einfach eine ZIP-Datei erstellt?!

Rechts oben in der Unraid WebGUI findest du das Icon ">_". Damit öffnet du das WebTerminal. Da diesen Befehl eingeben und mit Enter bestätigen: samba restart Entsprechende Fehlermeldungen hier posten. Dann unter SMB Settings schauen. Wie heißt da die Workgroup? Das selbe bei deinem MacBook prüfen: https://www.lifewire.com/configure-os-x-workgroup-name-mountain-lion-2260208 Lade außerdem mal deine Diagnosedatei hier hoch. Diese kannst du in der Unraid WebGUI unter Tools > Diagnose > Download erstellen lassen.

Also verstehe ich das richtig. Der Server startet aus dem Sleep per WoL und die beiden Platten schlafen noch. Das Plugin wird aber erst wieder aktiv, wenn 1x alle Platten each geworden sind? Klingt nach einem Bug des Plugins. EDIT: Dafür gibt es scheinbar eine Lösung. Und zwar diesen Code bei Pre und Post hinterlegen: for disknum in 1 `ls /dev/md* | sed "sX/dev/mdXX"`; do /usr/local/sbin/mdcmd spindown $disknum; done Damit wird Unraid angewiesen alle Platten herunterzufahren. Platten die gerade aktiv sind, fahren dann direkt wieder hoch, Platten die bereits schlafen, machen dann gar nichts. Scheinbar prüft das Plugin ob Unraid das Kommando ausgeführt hat. Das Kommando ist nicht optimal. Besser wäre es, wenn die laufende Disk ignoriert würde. Falls ich die Zeit finde, kann ich das anpassen.

Und hast du das Kommando im WebTerminal ausgeführt? Hast du die Workgroup kontrolliert?

OK, after testing several cards I accidentally found the problem. It's not an incompatibility, instead it was this powertop rule: # Enable SATA link power management #for i in /sys/class/scsi_host/host*/link_power_management_policy; do # echo 'med_power_with_dipm' > $i #done The same problem occurs if powertop --auto-tune has been executed. So the card / controllers driver has a problem with the SATA Device Power Management. This is sad as it saves much energy. Maybe I will realize this rules only for the onboard SATA ports. I will even check if HIPM is available and test those rules, too. Could this be a general problem with the JMicron controller?

Auf dem USB Stick gibt es zwei Dateien. Die /config/network.cfg und die /config/network-rules.cfg. Lösch diese beiden Dateien mal und starte den Server neu. Auf die Art sind die Netzwerk-Einstellungen zurückgesetzt auf DHCP. Du musst dann auf deinem Router nach der IP des Servers suchen bzw mit einem Tool wie Angry IP Scanner könntest du den Server ebenfalls finden. Sobald du dann wieder auf der WebGUI bist, kannst du natürlich wieder eine feste IP einstellen. Mit diesen Schritten hast du jedenfalls gewährleistet, dass die korrekten MAC-Adressen und Anzahl der Ports etc in den Config-Dateien hinterlegt sind (da Unraid sie dann komplett neu anlegt). Ich würde dann, wenn du eh nur ein Kabel angeschlossen hast, das Bonding unter Settings > Network Settings deaktivieren. Wenn das auch nicht hilft, dann würde ich mal einen anderen Port testen bzw wenn mehrere Kabel verbunden sind, nur eines anschließen. Dazu auch mal die Reihenfolge der Netzwerkbuchsen unter Interface Rules (ebenfalls unter Network Settings) so anpassen, dass der Port, den du nutzt, auch oben steht. Falls irgendwas nicht geht, kannst du jederzeit wieder die beiden Config-Dateien löschen und der Server holt sich wieder per DHCP eine IP.

Ja Ja Ja. Für VMs lassen manche die SSD sogar komplett aus dem Array raus und schleifen sie an die VM durch. Dadurch fällt der Overhead der virtuellen Festplattendatei/Treiber weg. @SpaceInvaderOne hat in diesem Video einen coolen Trick gezeigt, womit die Festplatte bei heruntergefahrener VM dann auch parallel in Unraid genutzt werden kann. Bedenke auch, dass sobald die Parität aktiv ist, dass die Schreibleistung einer SSD, die mit im Array liegt, auf ~70 MB/s durch die Paritätsberechnung limitiert ist. Es macht also für dich evtl mehr Sinn die SSDs alle als SSD Cache zu nutzen. Unraid stellt die dann als BTRFS RAID5 bereit. In Zukunft will Unraid übrigens mehrere Array Pools mit jeweils eigenem Paritätslaufwerk erlauben. Dann könnte man ein HDD Array und ein SSD Array parallel betreiben. Ja immer noch. Weil es gibt weder ein Board, das so sparsam ist wie das Fujitsu D3644, noch gibt es einen Nachfolger für den C246 Chipsatz außer vielleicht dem W480, aber die Auswahl ist bescheiden. Und bei den Consumer-Chipsätzen hast du das Problem ein bezahlbares Board mit 8 SATA Ports zu finden (du fängst ja jetzt schon an mit diversen SSDs). Zuletzt fehlt es der 10ten Generation eben an einem Pentium Gold oder i3 mit ECC Support. Aber das muss jeder selbst wissen.

Wir hatten vor kurzem schon einen Thread dazu: Ich würde sagen, dass man da jede Marke nehmen kann. Hauptsache man bekommt bei Defekt einen neuen Akku. Wenn man ein Produkt aus der EU haben will, lohnt vielleicht ein Blick auf AEG Power Solutions. Ich würde mir zu dem jeweiligen Modell auch die Bewertungen durchlesen. Manche stinken komischerweise.

Interesting. Having the SanDisk Ultra Fit here, too. And its the same problem. The Creator does not find it: I've tested executing the Creator as Admin and re-formatting the flash drive as well. I even used an USB3 to USB2 adapter cable to force the flash drive to work as USB2 device. Had no problems with other USB2 or USB3.x flash drives. It's time for a bug report ^^