Von hier:

On 12/29/2020 at 7:04 PM, T0a said:

Leider scheint Btrfs trotz einiger Fehlerbehebungen in Unraid 6.9 bezüglich hoher "Writes" immer noch enorm viele Schreibvorgänge bei einer Raid1 Konfiguration zu verursachen.

Das liegt nicht an BTRFS. BTRFS ist ein Dateisystem. Das macht nur das was man ihm sagt. Es kann aber gut sein, dass ZFS eine andere Blockgröße hat oder einfach anders mit dem überschreiben der Blocks umgeht.

 

Jedenfalls ist die Ursache meiner Ansicht nach in dem Healthcheck der verschiedenen Docker Container zu suchen. Bisher sind hier Plex und PiHole aufgefallen:

https://forums.unraid.net/bug-reports/stable-releases/683-unecessary-overwriting-of-json-files-in-dockerimg-every-5-seconds-r1079/

 

Die Lösung ist es bei jedem Container den Parameter --no-healthcheck bei den Extra Parameters zu übergeben:

 

Welcher Healthcheck aktiv hat, sieht man in der Docker Übersicht mit aktivem Advanced View:

 

Mit diesem Kommando kannst du übrigens die Schreibvorgänge des docker.img überwachen und in eine Log-Datei schreiben:

inotifywait -e create,modify,attrib,moved_from,moved_to --timefmt %c --format '%T %_e %w %f' -mr /var/lib/docker > /mnt/user/system/docker/recent_modified_files_$(date +"%Y%m%d_%H%M%S").txt

Auf die Art bin ich damals dahinter gekomme, steht aber auch in meinem Bug-Report. Mein Bug-Report bei Docker wurde leider ignoriert. Der Fehler liegt nämlich bei denen. Die überschreiben ständig unnötig JSON-Dateien und dadurch, dass bei Unraid ein docker.img und eine hohe Blockgröße existiert, resultiert daraus ein höherer Traffic auf den Laufwerken.

 

Jedenfalls konnte ich das Problem damit lösen.

 

@Squid hat übrigens irgendwo mal vorgeschlagen das docker.img aufzulösen und stattdessen einen realen Pfad zu nutzen, aber ich glaube das ging nur bei der aktuellen Beta und ich weiß auch leider nicht mehr wo er das geschrieben hat ^^

 

 

 

 

Quote

Jedenfalls ist die Ursache meiner Ansicht nach in dem Healthcheck der verschiedenen Docker Container zu suchen. Bisher sind hier Plex und PiHole aufgefallen:

Danke für deine Antwort @mgutt. Ich hatte die Diskussion um die negativ in Erscheinung getretenen Container bezüglich der Schreibvorgänge ebenfalls verfolgt. Soweit ich weiß, hat Limetech ein paar Anpassungen an der Art wie das docker.img gespeichert wird durchgeführt.

 

Die vielen Schreibvorgänge sind bei Btrfs leider auch ohne Docker ein Problem. Ich versuche gerade den Thread hier im Forum zu finden. Aus meiner Erinnerung waren die Schreibvorgänge eines Btrfs Raid1 im Vergleich zu einer einzelnen XFS formatierten Festplatte um den Faktor 4 höher. Begründet wurde dies durch die vielen zusätzlich geschriebenen Metadaten (Update: Thread)

Edited December 29, 20205 yr by T0a

1 minute ago, T0a said:

Die vielen Schreibvorgänge sind bei Btrfs leider auch ohne Docker ein Problem. Ich versuche gerade den Thread hier im Forum zu finden.

Gerne.

Hier ist der Thread von dem ich gesprochen habe. Relevant sind der verlinkte Post und folgende. Was haltet ihr davon die Diskussion ab diesem Post hier zu trennen und in ein neues Thema zu verschieben?

Edited December 29, 20205 yr by T0a

1 hour ago, mgutt said:

@Squid hat übrigens irgendwo mal vorgeschlagen das docker.img aufzulösen und stattdessen einen realen Pfad zu nutzen, aber ich glaube das ging nur bei der aktuellen Beta und ich weiß auch leider nicht mehr wo er das geschrieben hat ^^

If google translate is doing its job, I believe your thinking about https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-690-beta24-available-r981/

 and specifically https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-690-beta24-available-r981/?tab=comments#comment-9777

 

 

I am a big fan of this as it solves a ton of problems and by definition will always involve the least amount of writes.  (And for the "old timers" this is actually how docker was originally introduced on Unraid).  Downside is that it requires 6.9, I'm the only one using it, all forum posts talk about the "image", and I'm not sure if the driver necessary for the folder to be placed on ZFS is included in the system / plugin at all...

1 hour ago, Squid said:

 I believe your thinking about

Yes, this is was I meant:

Quote

We also added the ability to bind-mount a directory instead of using a loopback.  If file name does not end with ".img" then code assumes this is the name of directory (presumably on a share) which is bind-mounted onto /var/lib/docker.

Thanks for the hint!

4 hours ago, T0a said:

Hier ist der Thread von dem ich gesprochen habe. Relevant sind der verlinkte Post und folgende.

JorgeB spricht dort von einer hohen "Write Amplification". Hier sagt er aber auch, dass das ein generelles Problem aller Copy on Write Dateisystem ist, also auch bei ZFS.

 

Ein Zitat aus Wikipedia:

Quote

Bei Dateisystemen bedeutet Copy-On-Write, dass geänderte Blöcke nicht überschrieben, sondern zunächst vollständig an einen freien Platz kopiert werden. Danach werden Verweise auf den Block in den Metadaten aktualisiert.

Das heißt also, dass wenn in einer Datei Daten aktualisiert werden, dass die zugehörigen Blöcke vollständig an einer anderen Stelle neu erstellt werden. Zusätzlich wird das noch in separaten Meta-Blöcken "notiert".

 

Wenn ich zB diese Frage/Antwort lese, werde ich direkt an unser Problem mit BTRFS erinnert, dabei geht es aber um ZFS.

 

Hier gibt es eine Diskussion ob man SSDs mit ZFS nutzen sollte und das Argument vom dortigen cyberjock ist, dass sie ja "nur" 10-20% schneller kaputt gehen, aber das das keinen jucken würde, weil die SSD trotzdem lange genug hält und vorher ausgetauscht wird, weil sie zwischenzeitlich zu klein geworden sind.

 

Mein Fazit ist daher, dass man mit diesem Nachteil bei COW Dateisystem einfach leben muss. Und wenn das nicht kann, dann muss man sich was anderes einfallen lassen. Vielleicht wäre ja lsyncd eine Idee (lsyncd Slackware Paket). Damit könnte man zwei SSDs live synchron halten. Also ein selbst gebautes RAID1 mit zwei XFS SSDs. Für ein RAID56 bräuchte es dann schon härtere Geschütze wie Snapraid mit dem man ja bekanntlich zeitversetzt Paritätslaufwerke erstellen kann (Snapraid Slackware Paket). Das wäre dann mein Favorit, da ich zeitversetzt eh bevorzuge. Das würde ich mir optional auch für Unraid wünschen.