Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Jimini

PCGH-Community-Veteran(in)
Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Aloha,

wie ich vorhin feststellen musste, ist mein ext4-RAID5 an die 32bittige Grenze von circa 16 Terabyte gestoßen - ein Vergrößern von 15 auf 18 TB ist somit nicht möglich.
Zwar unterstützen die e2fsprogs seit geraumer Zeit den Betrieb in 64 Bit, allerdings werden entsprechende Dateisysteme per default mit dem Parameter "auto_64-bit_support = 1" formatiert. Dieser führt dazu, dass das Dateisystem nur im Bedarfsfall mit 64 Bit angelegt wird.
Im Klartext: bei weniger als 16TB bleibt alles in 32 Bit, bei mehr als 16TB wird es in 64 Bit formatiert.

Das ist insofern ärgerlich, als dass ein einfacher Vergrößern nun nicht möglich ist. Es ist demnach dringend anzuraten, von Anfang an auf 64 Bit zu setzen, wenn absehbar ist, dass irgendwann in der Zukunft mehr als 16TB genutzt werden sollen.
Ansonsten bleibt nur das Sichern der Daten, eine Neuformatierung und das Zurückspielen des Backups.

MfG Jimini
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Wobei bei solchen Datenmengen auch über die Verwendung von ZFS nachzudenken ist.
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

ZFS hat aber zwei gewichtige Nachteile:
a) Wird es meines Wissens nicht vom Linux-Kernel mitgebracht, sondern muss im Userspace laufen.
b) Braucht es extrem viel RAM. Unter 8GB kann man es ziemlich knicken, und bei 16TB Speicherplatz müsste ich dann mindestens 16GB Speicher verbauen - je nachdem, welche Features man nutzen möchte.

MfG Jimini
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Aber halt auch sehr große Vorteile, unter anderem den Vorgang des rebuilds, den Schutz gegen Veränderung der Daten, Snapshots sowie den Wegfall eines Inits.
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Aber halt auch sehr große Vorteile, unter anderem den Vorgang des rebuilds, den Schutz gegen Veränderung der Daten, Snapshots sowie den Wegfall eines Inits.
Das stimmt schon - insbesondere Snapshots reizen mich. Ich habe lange überlegt, ob ich nicht wegen ZFS auf *BSD migriere. Aber mittlerweile ist die Config des Systems so ausgefeilt, dass ich nicht nochmal bei nahezu Null anfangen möchte.
BTRFS traue ich noch nicht so ganz über den Weg, da warte ich lieber noch 5 Jahre.

Immerhin habe ich ein zweites, nahezu identisches System, auf welchem die Daten ein zweites Mal liegen. Aber ein kompletter Sync sowie das Transferieren von ~15TB Daten ist halt schon nervig, weil zeitaufwändig.

MfG Jimini
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Das stimmt schon - insbesondere Snapshots reizen mich. Ich habe lange überlegt, ob ich nicht wegen ZFS auf *BSD migriere. Aber mittlerweile ist die Config des Systems so ausgefeilt, dass ich nicht nochmal bei nahezu Null anfangen möchte.
BTRFS traue ich noch nicht so ganz über den Weg, da warte ich lieber noch 5 Jahre.
ZFS für Linux ist eigentlich ziemlich trivial und ist eigendlich ziemlich ausgereift. https://clusterhq.com/2014/09/11/state-zfs-on-linux/ Dateisystem ZFS on Linux bereit für Alltagseinsatz | heise open Ich kenne auch einige Firmen die es im Produktiveinsatz haben. Das selbe gilt eigendlich auch für btrfs, das ist ja für einige Distris schon Standart.
Btrfs-Erfinder stuft sein Linux-Dateisystem als stabil ein | heise open
Immerhin habe ich ein zweites, nahezu identisches System, auf welchem die Daten ein zweites Mal liegen. Aber ein kompletter Sync sowie das Transferieren von ~15TB Daten ist halt schon nervig, weil zeitaufwändig.

MfG Jimini
Na ja, eigentlich ist das ein Task den ich vor einem Urlaub starten würde :D Beaufsichtigung sollte das ja nicht brauchen.
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Naja, ~2Tage Dauerbetrieb.

Aber schon krass das Ext4 als Default 32 Bit nimmt.
Wohl ohne Nachfrage?
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Das selbe gilt eigendlich auch für btrfs, das ist ja für einige Distris schon Standart.
Ich bin da dennoch vorsichtig - auch, weil das "Standard"-Argument so eine Sache ist: Red Hat oder SuSe boten BTRFS schon verdammt früh als default-Option an - wenn ich mich nicht irre, war das damals noch nicht für den Produktivbetrieb freigegeben.
Zudem hatte ich vor 2 Jahren oder so mal ziemlich dicke Probleme mit BTRFS, welches regelmäßig den Rechner für ein paar Minuten komplett lahmlegte.
Naja, ~2Tage Dauerbetrieb.
Allein das Syncen dürfte 1,5 bis 2 Tage dauern. Das Kopieren der Daten dürfte auch nochmal rund 2 Tage in Anspruch nehmen. Wobei die Daten zwischen zwei verschlüsselten Software-RAID5 hin- und her kopiert werden, welches natürlich keine Gigabit-Leitung auslastet.
Aber schon krass das Ext4 als Default 32 Bit nimmt.
Wohl ohne Nachfrage?
Jop - ich habe da bis heute nicht einmal dran gedacht, dass das Dateisystem da so einen Pferdefuß mitbringt. Denn das Szenario "ich kaufe nach und nach Festplatten und habe irgendwann mehr als 16TB" ist ja nicht mehr sooo abwegig.

Vielleicht mache ich die Tage mal einen Bugreport auf, vorher informiere ich mich aber nochmal.

MfG Jimini
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Zumal man das Limit bereits mit 2 Festplatten erreicht.
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Allein das Syncen dürfte 1,5 bis 2 Tage dauern. Das Kopieren der Daten dürfte auch nochmal rund 2 Tage in Anspruch nehmen. Wobei die Daten zwischen zwei verschlüsselten Software-RAID5 hin- und her kopiert werden, welches natürlich keine Gigabit-Leitung auslastet.
ZFS macht keinen initial resync. Daher dauert das Einrichten nur wenige Minuten. Auch kommt es halt mit verschiedenen Festplattengrößen sehr gut zurecht. Was man halt oft vergisst ist, das ZFS mehr ist als ein Dateisystem. Es ist die komplette Verwaltung dazu.

BTRFS ist übrigend selbst für RHEL und SLES stable genug. Ein paar als experimentell gekennzeichnete Features sind zwar abgeschaltet, da nicht ausreichend getestet, aber der Großteil ist integriert. Bei SLES 12 ist es auch das StandartFS.
 
Zuletzt bearbeitet:
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

ZFS macht keinen initial resync. Daher dauert das Einrichten nur wenige Minuten.
Ja, ich bezog mich hier auf das RAID5 :)
BTRFS ist übrigend selbst für RHEL und SLES stable genug. [...] Bei SLES 12 ist es auch das StandartFS.
Ich bin da übervorsichtig - eine schleichende Dateninkonsistenz o.ä. wäre mein absoluter Horror, da in den Daten jahrelange Arbeit drinsteckt. Daher bleibe ich momentan bei dem, was sich bislang bewährt hat.

In den nächsten Tagen teste ich mal, ob die Daten bestehen bleiben, wenn ich das Dateisystem lösche und direkt (größer) neu anlege. ext4 ist da ja vergleichsweise robust.

MfG Jimini
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Ich bin da übervorsichtig - eine schleichende Dateninkonsistenz o.ä. wäre mein absoluter Horror, da in den Daten jahrelange Arbeit drinsteckt. Daher bleibe ich momentan bei dem, was sich bislang bewährt hat.
Genau dafür gibts eigendlich ZFS :D
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Wie verhält sich ext4 in einer LVM/LVG?
Gibts dann auch die Kapazitätsgrenze?
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Genau dafür gibts eigendlich ZFS :D
Richtig, aber ~18GB RAM pro System (!) nur für das Dateisystem wären mir aktuell schlichtweg zu teuer. Da bräuchte ich dann insgesamt 40 bis 48GB, was mich 200 bis 240 € kosten würde. Und beim nächsten Plattenupgrade dürfte ich dann auch wieder Speicher nachrüsten ;)
Wie verhält sich ext4 in einer LVM/LVG?
Gibts dann auch die Kapazitätsgrenze?
Das dürfte egal sein, was "unter" dem Dateisystem liegt, daher vermute ich "ja".

MfG Jimini
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Dass ZFS viel RAM benötigt und von noch mehr RAM durchaus die Performance profitiert, ist wahr. Allerdings benötigt man nicht zwangsweise 1 GB RAM pro 1 TB Speicher. Mit 16 GB RAM ist man breits gut dabei, selbst wenn man mehr als 16 TB Speicher hat. Natürlich gibt es hier auch Außnahmen. Deduplication benötigt z.B. bei weitem mehr RAM. Berücksichtigen sollte man auch Dienste, die auf dem Server laufen und eventuell einiges an RAM beanspruchen. Diese Milchmädchenrechnung von wegen 1 GB RAM pro 1 TB HDD als Mindestanforderung halte ich jedenfalls für wenig sinnvoll.

Wichtiger ist hier meiner Meinung nach die Verwendung von ECC RAM, falls man auf ZFS setzt.
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

[...]Allerdings benötigt man nicht zwangsweise 1 GB RAM pro 1 TB Speicher. Mit 16 GB RAM ist man breits gut dabei, selbst wenn man mehr als 16 TB Speicher hat. Natürlich gibt es hier auch Außnahmen. Deduplication benötigt z.B. bei weitem mehr RAM. Berücksichtigen sollte man auch Dienste, die auf dem Server laufen und eventuell einiges an RAM beanspruchen. Diese Milchmädchenrechnung von wegen 1 GB RAM pro 1 TB HDD als Mindestanforderung halte ich jedenfalls für wenig sinnvoll.
Da hast du recht, irgendwie hat sich die Faustregel à la "1GB Speicher pro TB Speicherplatz" bei mir festgesetzt. Danke für die Richtigstellung! :)
Aber selbst wenn 16GB RAM genügen - das System fährt momentan mit rund 6GB RAM, da ich einige etwas speicherintensivere Daemons laufen habe. Somit würde ich 22GB RAM nur für den Fileserver (und weitere 18GB für den Backupserver) benötigen und dabei deiner Aussage zufolge nicht alle Features von ZFS nutzen können. Daher ist ZFS für mich aktuell keine Alternative - zumindest nicht, bis RAM wieder deutlich billiger wird.

ECC-Speicher wäre natürlich sehr sinnvoll, zieht allerdings auch wieder weitere Kosten nach sich.

MfG Jimini
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

Aber selbst wenn 16GB RAM genügen - das System fährt momentan mit rund 6GB RAM
Klar, letztendlich benötigt man einfach mehr RAM als bei alternativen Lösungen. Nur ist es eben nicht so extrem, wie oft behauptet wird.

nicht alle Features von ZFS nutzen können
Nur Deduplication. Und das würde ich auch nicht als das absolute Killer-Feature von ZFS bezeichnen. Ich habe zumindest kein Problem damit, darauf zu verzichten. Würde mir für mein Home-NAS auch nichts bzw. nicht viel bringen.
 
AW: Hinweis zum Betreiben größerer Festplattenverbünde mit ext4

ECC-Speicher wäre natürlich sehr sinnvoll, zieht allerdings auch wieder weitere Kosten nach sich.

Bei einem Neukauf ist der Unterschied gar nicht so tragisch.
Nachträglich aber natürlich teuer, speziell wenn man auch noch ein passendes Mainboard/CPU braucht.
 
Zurück