Neu ist meine Antipathie gegen ext4 nicht — nur gerechtfertigt. Mein Haß gegen dieses unfertige Stümper-FS ist allerdings jüngst neu entfacht worden …
All über all auf den Tannenspitzen sah man jüngst ext4-Lobhudeler sitzen — also gab ich diesem Stümper-FS noch einmal eine Chance; bleibt einem ja auch fast keine Wahl, ist es doch der Default der meisten Distributionen derzeit.
Mein Vertrauen wurde, wie nicht anders erwartet, schmählich enttäuscht:
Apr 4 01:26:28 localhost kernel: [5968717.993498] sd 5:0:0:0: [sdb] 62535680 512-byte logical blocks: (32.0 GB/29.8 GiB) Apr 4 01:26:28 localhost kernel: [5968717.994352] sd 5:0:0:0: [sdb] Assuming drive cache: write through Apr 4 01:26:28 localhost kernel: [5968717.997238] sd 5:0:0:0: [sdb] Assuming drive cache: write through Apr 4 01:26:28 localhost kernel: [5968717.997245] sdb: sdb1 sdb2 Apr 4 01:26:29 localhost kernel: [5968719.437463] EXT4-fs error (device sdb2): file system corruption: inode #8 logical block 153 mapped to 196761 (size 1) Apr 4 01:26:29 localhost kernel: [5968719.437491] BUG: unable to handle kernel paging request at 023bc000 Apr 4 01:26:29 localhost kernel: [5968719.437495] IP: [] __percpu_counter_sum+0x2a/0x70 Apr 4 01:26:29 localhost kernel: [5968719.437504] *pde = 00000000 Apr 4 01:26:29 localhost kernel: [5968719.437507] Oops: 0000 [#1] SMP
Die ext4-Geilisten haben es offensichtlich nie auf ARM getestet — mein Raspberry Pi-basierter Test-VDR verstarb nach vielleicht grade einer Woche mit obigen letzten Grüßen — der fsck.ext4 war deutlich textreicher, was bedeutet, daß das FS einfach im Arsch ist ==> ext4, die umständliche Variante von /dev/null …
Noch mehr Impact wird ext4 bei meinem als NFS-Dump mißbrauchten FHEM-Server haben, denn dort sagt das per NFS exportierte Verzeichnis:
root@plug-2:~# df -h | grep -i nfs /dev/sda3 679G -16T 16T - /nfs/data_fhem
Im dmesg liest sich das so:
[12619269.389874] EXT4-fs (sda3): delayed block allocation failed for inode 38145598 at logical offset 0 with max blocks 5 with error -28 [12619269.402104] EXT4-fs (sda3): This should not happen!! Data will be lost [12619269.402111] [12619269.411313] Total free blocks count 0 [12619269.415272] Free/Dirty block details [12619269.419124] free_blocks=0 [12619269.422067] dirty_blocks=-4273830918 [12619269.425916] Block reservation details [12619269.429850] i_reserved_data_blocks=5 [12619269.433709] i_reserved_meta_blocks=1
Naja, da schon 36 GB nicht zu recovern waren, kann ich die 679 GB wohl auch abschreiben. Damit hat dann ext4 mehr Daten im Frieden (== ohne HW-Fehler) vernichtet als alle anderen Filesysteme im Krieg (== mit HW-Fehlern der Platten). Reife Leistung — ergo:
FTR: ich nutze in den entsprechenden Szenarien ext3 seit Jahr(zehnt)en ohne derlei Probleme; falls ein ext3 mal in Probleme gerät, bringt ein fsck es i. d. R. wieder in einen sauberen Zustand — nicht so bei ext4 :(