ext4 - wer verwendet es, wer kennt sich aus?

ext4 - wer verwendet es, wer kennt sich aus? (7 Beiträge, 359 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich bin gerade schweinesauer wegen
http://forum.geizhals.at/t798803,6844517.html#6844517

Nachdem die Mehrheit meines Wissens nach auf ext4 setzt:
Habe ich das Filesystem falsch angelegt?

Das externe Log ist bei mir auf einem 1GB-großen LV in einer VG ("system"), die auf 2 md sitzt:

md4 : active raid1 sdg3[0] sdh3[1]
      615337559 blocks super 1.2 [2/2] [UU]
      
md3 : active raid1 sdg2[0] sdh2[1]
      117025408 blocks [2/2] [UU]

Die VG hat eine PE-Size von 4MB.

Die Daten selbst liegen in einer ca. 1TB-großen LV in einer VG ("sata"), die auf einem md liegt:

 md1 : active raid5 sda2[0] sdf2[6] sde2[4] sdd2[3] sdc2[2] sdb2[1]
      9767048960 blocks super 1.2 level 5, 256k chunk, algorithm 2 [6/6] [UUUUUU]

Diese VG hat eine PE-Size von 32 MB.

Das Filesystem habe ich wie folgt angelegt:

mke2fs -O journal_dev /dev/system/backuppc-log 
mkfs.ext4 -b 4096 -E stride=64 -E stripe-width=320 -J device=/dev/system/backuppc-log -O dir_index,extent,large_file,resize_inode,sparse_super,uninit_bg /dev/sata/backuppc

Der fstab-Eintrag sieht so aus:

/dev/sata/backuppc	/usr/local/BackupPC/daten ext4 noatime,nodiratime 0 2

Was mache ich falsch? Oder ist ext4 einfach schrottig???

mke2fs -O journal_dev /dev/system/backuppc-log
mkfs.ext4 -b 4096 -E stride=64 -E stripe-width=320 -J device=/dev/system/backuppc-log -O
dir_index,extent,large_file,resize_inode,sparse_super,uninit_bg
/dev/sata/backuppc

Hm, du legst zuerst das Journal an. Lasst da aber da die Blocksize die Heuristik erledigen. Danach legst du ein Filesystem an, und erzwingst eine Blocksize.

Nun steht aber, in der Doku sehr klar, dass journal und FS die selbe Blocksize haben müssen.

Könnte ich mir mal so als Ursache vorstellen. Ganz generell halte ich soclhe Spielereien mit dem Filsystem aber eher als

--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Es ist eine Suende, alle dieser Parameter zum Feintuning des Dateisystems quasi aus einer plumpen Vermutung heraus manuell zu spezifizieren. In den letzten Jahren ist der Block-Layer unter Linux sehr "feinfuehlig" geworden - disks, md und LVM kommunizieren mittlerweile quasi alle wichtigen Attribute der ihnen zugrundeliegenden Medien via sysfs, und mdadm, lvm2 und mkfs (zumindest fuer e2fs und xfs) interpretieren diese Informationen entsprechend und optimieren ihre Parameter aufgrund dieser Daten - und zwar so, wie die Entwickler dieser Stacks dies fuer sinnvoll erachten - selbsttaetig.

Wenn man also nicht absolut sicher und empirisch belegt weisz, dass diese selbstgewaehlten Parameter fuer die zu erwartende Workload die absolut richtige, weil bessere Entscheidung sind, sollte man es einfach sein lassen. "Premature optimization" und so.

Es ist eine Suende, alle dieser Parameter zum Feintuning des Dateisystems
quasi aus einer plumpen Vermutung heraus manuell zu spezifizieren.

Was an meiner Vermutung war plump???

In den
letzten Jahren ist der Block-Layer unter Linux sehr "feinfuehlig" geworden -
disks, md und LVM kommunizieren mittlerweile quasi alle wichtigen Attribute
der ihnen zugrundeliegenden Medien via sysfs, und mdadm, lvm2 und mkfs
(zumindest fuer e2fs und xfs) interpretieren diese Informationen entsprechend
und optimieren ihre Parameter aufgrund dieser Daten - und zwar so, wie die
Entwickler dieser Stacks dies fuer sinnvoll erachten - selbsttaetig.

1.) Einiges kann kein Automatismus wissen, beispielsweise die Zugriffsmuster (große oder viele Dateien? Parallele oder Serialisierte Zugriffe? ...) auf die Devices -  oder wieviel RAM oder Speicherplatz ich opfere, um schnellere Zugriffe zu gewinnen.

2.) Was blieb denn von meinen Parametern über, was anders gewählt hätte werden können?

Blocksize 4KB  (erlaubst sind 1, 2 oder 4KB): Ist bei "extended Format"-HDs sicher die einzige Option. Ebenso durch die Größe bedingt.

stride 64 Die chunk-Size ist 256 KB, stride laut manpage die Anzahl der Blocks, bis die nächste Disk drankommt... Also 256K/4K=64

stripe-width 320Laut manpage: stripe-Width=stride-size * N, N=die Anzahl der Datensisks (bei RAID5 die Anzahl der Disks-1).

dir_index erhöht über Indizes die Suchen in großen Direktories

extentThis  is  a  much more efficient encoding which speeds up  filesystem  access,  especially for large files.

large_file Für Dateien größer 2GB

resize_inode Erlaubt das wachsen der Inoden

sparse_super Weniger Superblock-Kopien und daher sparsamer

uninit_bg Nicht alle Blockgroups initialisieren

Welche von den Optionen ist fehlerträchtig??

Die letzten paar Optionen sind übrigens Beispiele, die ein Automatismus nie wissen kann... Weil er nie wissen kann, ob Dateien > 2GB draufkommen, ob ich genug Ram für den dir_index opfern will, ...

Hm, du legst zuerst das Journal an. Lasst da aber da die Blocksize die
Heuristik erledigen. Danach legst du ein Filesystem an, und erzwingst eine
Blocksize.

Stimmt... Ich wollte das Kommando mal so absetzen (um die Syntax so zu testen) únd nachher mit Blocksize herumspielen.

Fakt war aber, dass man an der Ausgabe des Kommandos sah, dsas eh auch Blöcke mit 4KB erzeugt wurden.

Dadurch musste ich nicht extra nochmal das Kommando mit 4KB Blocksize absetzen.

Nun steht aber, in der Doku sehr klar, dass journal und FS die selbe Blocksize
haben müssen.

... war also gegeben.

Gibt es noch andere Fehler in dem Aufruf?

Nur eine Anmerkung: 'noatime' impliziert 'nodiratime'.

Yup... Bei XFS zumindest sicher. Ich war mir nicht sicher, ob das für alle FS gilt - daher hab ich diesen gleichbleibenden Teil in der fstab beim Tests mit unterschiedlichen FS...

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung