Dateisystem optimieren

  • Hier läuft seit 18 Monaten eine Überwachungskamera mit dem motion server und einer externen USB-Festplatte mit ext4 Dateisystem. Betriebssystem ist das debian-basierte Standard-OS für Raspi3.

    Die Festplatte hatte in letzter Zeit zwei Ausfälle (verlorene Blöcke), die sich mit e2fsck beheben ließen. Ich habe schon eine neue Platte am Start stelle mir grade die Frage, ob man das Dateisystem vielleicht optimieren sollte. Dort landen im Jahr hunderttausende JPEG-Bilder in der Größe zwischen 16 und 25 kB. Würde es sinnvoll sein, die Blockgröße eines neuen Dateisystems auf 32 kB, also ein Block pro Bilddatei, festzulegen? Ich kenne mich mit den Details dieser Systeme nicht so aus, und habe vielleicht ein falsche Bild von der Funktionsweise.

  • Wenn das Verhältnis von i-Nodes zu Blöcken auch bei einer relativ vollbeschriebenen Partition noch halbwegs vernünftig erscheint, gäbe es keinen Grund, von der Default Einstellung abzuweichen. Je grösser die Blocksize, desto mehr unbenützbare, freie Sektoren im letzen beschriebenen Datenblock.


    Wenn Du die Blocksize von (default) 4 kB auf 32 kB erhöhst, werden bei jedem Schreibuigriff mindestens 32 kB, also ein Block verbraucht, auch wenn nur 16, oder 25 kB an Nutzerdaten darin beschrieben werden. Die nicht benutzen Sektoren in diesem Block können auch nicht anderweitig genutzt werden, weil der gesamte Block an einen Inode gebunden ist.


    Zeig mal Deinen Filsystemheader des aktuellen EXT4-Filesystems, damit abgrschätzt werden kann, ob sich eine Blocksize von höchsens 8 kB pberhaupt lohnt. (z.B. mit tune2fs -l /dev/DeinePartition).



    Servus !

    Wer nichts weiß, muss alles glauben.

  • Bitteschön


    $ sudo tune2fs -l /dev/sda1
    tune2fs 1.43.3 (04-Sep-2016)
    Filesystem volume name:
    Last mounted on: /mnt/motion
    Filesystem UUID: f9e7f851-d04c-4f81-9c2a-44b9e27e1c4e
    Filesystem magic number: 0xEF53
    Filesystem revision #: 1 (dynamic)
    Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
    Filesystem flags: signed_directory_hash
    Default mount options: user_xattr acl
    Filesystem state: clean
    Errors behavior: Continue
    Filesystem OS type: Linux
    Inode count: 61054976
    Block count: 244190208
    Reserved block count: 12209510
    Free blocks: 232973707
    Free inodes: 60061663
    First block: 0
    Block size: 4096
    Fragment size: 4096
    Reserved GDT blocks: 965
    Blocks per group: 32768
    Fragments per group: 32768
    Inodes per group: 8192
    Inode blocks per group: 512
    RAID stride: 32750
    Flex block group size: 16
    Filesystem created: Sat Mar 11 10:23:50 2017
    Last mount time: Mon Jul 23 18:30:40 2018
    Last write time: Mon Jul 23 18:30:40 2018
    Mount count: 1
    Maximum mount count: -1
    Last checked: Mon Jul 23 18:28:27 2018
    Check interval: 0 ()
    Lifetime writes: 63 GB
    Reserved blocks uid: 0 (user root)
    Reserved blocks gid: 0 (group root)
    First inode: 11
    Inode size: 256
    Required extra isize: 28
    Desired extra isize: 28
    Journal inode: 8
    Default directory hash: half_md4
    Directory Hash Seed: 65fd43ee-72e0-4c42-89ec-0adfb7ea1bda
    Journal backup: inode blocks

  • Für mich läuft die Ext4 Partition für Deine Filegtössen optimal.


    Das Verhältnis von Inodes zu (4k-)Blöcken von rd. 1 : 4 ist nahezu konstant,

    auch bei den noch freien [Free blocks: 232.973.707, Free inodes: 60.061.663]

    von Gesamt ------------------Block count: 244.190.208, Inode count: 61.054.976

    verbraucht -------------------------------------11.216.501, --------------------- 993.307


    Bei Deiner Partitionsgrösse von 1 TB hast Du noch nicht einmal 10 % an Nutzdaten verbraucht. Es ist Geschmacksache, ob Du die neue Platte mit 4k Blöcken, oder 8k Blöcken EXT4 formatierst-


    Wenn der Pi aber rund um die Uhr läuft und jein Root-Filesystem beinhaltet, solltest Du allenfalls die nachfolgenden Parameter im Auge behalten ggf. ändern:


    [Filesystem state: clean]

    Errors behavior: Continue
    Reserved block count: 12209510Check interval: 0


    Ob die Platte wirklich schon mit Badblocks belastet ist, kannst Du mit < badböcks > oder < e2fsck -c > ergründen.


    Die tatsächlich derzeit ungenutzen Inodes und freien Blöcke in den EXT4-FS-Gruppen (Gruppe 0 und 1 sind die FS-Metadaten/Superblocks, Nutzdaten ab Gruppe 2) findest Du mit < dumpe2fs > heraus.



    Servus !

    Wer nichts weiß, muss alles glauben.

  • Vielen Dank. Ich werde eine Ersatzplatte bei den Leuten vor Ort deponieren, und bei Bedarf lässt sich ein Austausch per Telefonverbindung regeln. Ich bin mir ziemlich sicher, dass Badblocks vorhanden sein müssten, werde das aber heute Nacht nochmal testen.