[gelöst] Unerklärliche Plattenbelegung

    Ich habe hier einen VDR mit einer Platte (RAID1) folgender Größe (Ausgabe von 'fdisk -l' bzw. 'df -h':


    Disk /dev/md2: 1.8 TiB, 1978766524416 bytes, 3864778368 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 4096 bytes

    I/O size (minimum/optimal): 4096 bytes / 4096 bytes

    /dev/md2 1.8T 1.7T 77G 96% /video


    Ein zweiter VDR hat diese Platte:


    Disk /dev/md126: 1.8 TiB, 2000397729792 bytes, 3907026816 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 4096 bytes

    I/O size (minimum/optimal): 4096 bytes / 4096 bytes

    /dev/md126 1.8T 1.7T 3.9G 100% /video


    Die beiden Platten sind exakt gleich befüllt, was ich mit


    rsync -aHSx --numeric-ids --delete --force


    sichergestellt habe.

    Nun sollte man meinen, dass die erste Platte, mit weniger Bytes und Sektoren als die zweite, weniger freien Platz hat. Es ist aber genau umgekehrt.

    Beide Systeme laufen unter openSUSE Leap 15.0. Die Platten sind mit EXT4 formatiert.

    Die physikalischen Platten sind sogar identisch (Seagate ST2000LM007), und bei der zweiten ist die gesamte Platte *eine* Partition:


    Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 4096 bytes

    I/O size (minimum/optimal): 4096 bytes / 4096 bytes

    Disklabel type: dos

    Disk identifier: 0x573f8509

    Device Boot Start End Sectors Size Id Type

    /dev/sda1 2048 3907029167 3907027120 1.8T fd Linux raid autodetect

    während bei der ersten neben der Video-Partition noch zwei System-Partitionen und eine EFI-Partition existieren:


    Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 4096 bytes

    I/O size (minimum/optimal): 4096 bytes / 4096 bytes

    Disklabel type: gpt

    Disk identifier: 08BA7481-879C-42C2-BA35-A8CD7267E076

    Device Start End Sectors Size Type

    /dev/sda1 2048 321535 319488 156M EFI System

    /dev/sda2 321536 21286911 20965376 10G Linux RAID

    /dev/sda3 21286912 42250239 20963328 10G Linux RAID

    /dev/sda4 42250240 3907028991 3864778752 1.8T Linux RAID


    Hat jemand eine Idee, woran das liegen könnte?

    Ich stehe vor einem Rätsel.


    Klaus

    Hallo Klaus,


    was sein kann, ist daß auf dem einen System die Directories mehr Platz benötigen ... wenn z.B. in einem Verzeichnis mal viele Dateien waren, wird die Inode für den Directory-Eintrag größer. Wenn die Dateien gelöscht werden, wird die Inode aber nicht mehr verkleinert ... wenn Du das leere Verzeichnis nun auf die andere Kiste kopierst, wird dort nur eine Inode für ein leeres Directory angelegt, welche kleiner ist ...


    Oder die Optionen für die Formatierung sind unterschiedlich, z.B. unterschiedliche Anzahl Inodes oder unterschiedliche Mindest-Blockgrößen ... Zum Prüfen einmal tune2fs -l <DEVICE>


    Alternativ kann es sein, daß Du z.B. Dateien gelöscht hast, die noch offen gehalten sind ... der rsync sieht die nicht und kann sie nicht kopieren, allerdings belegen sie auf dem Quell-System noch Platz, solange die Datei offen gehalten wird ... kann man prüfen mittels


    lsof +aL1


    Gruß,


    Space

    'lsof +aL1' zeigt keine offen gehaltenen Dateien auf diesen Platten an.


    Der Kopiervorgang ging von der Platte, auf der mehr Platz frei ist, zu der, auf der jetzt weniger frei ist. Also dürfte die Größe der Inodes auch nicht der Grund sein, denn das hätte ja, wenn, dann in die andere Richtung gehen müssen.


    Die Ausgaben von 'tune2fs -l' sehen so aus:

    Klaus

    Beim reserved block count scheint der Unterschied zu sein:


    Reserved block count: 483097


    vs


    Reserved block count: 24418917


    Unterschied dürften etwas mehr als 90G sein ... Sollte man mit tune2fs -m verändern können.


    Gruß,


    Space

    Auf der ersten Platte hast Du 1% reserviert ... also tune2fs -m 1 /dev/md126

    Danke, das könnte hinkommen.

    Jetzt ist nur die Frage, ob ich das einfach so an den beiden physikalischen Platten ändern kann, und ob/wie sich das dann auf das RAID1 auswirkt. Da das eine reine Video-Platte ist, brauche ich eigentlich gar keine "reserved blocks".


    Klaus

    Ne, das ist die Reservierung vom Filesystem (ext4) ... hat nichts mit dem Raid zu tun und sollte eigentlich problemlos online gehen ...


    Gruß,


    Jogi

    Ich habe das jetzt mit


    tune2fs -r 483097 /dev/sda1

    tune2fs -r 483097 /dev/sdb1

    tune2fs -r 483097 /dev/md126


    geändert und jetzt habe ich


    /dev/md126 1.8T 1.7T 96G 95% /video


    genau wie erwartet :-). Wahrscheinlich hätte auch der letzte tune2fs-Aufruf gereicht, weil ja nur dort ein Filesystem existiert. Aber bei den ersten beiden gab es zumindest keine Fehlermeldung.


    Danke für deine Hilfe!


    Klaus

    Wenn ich mich nicht verrechne sind es auf der 1.Platte sogar nur 0,1%.

    Ich kann es garade nicht ausprobieren, aber kann tune2fs mit -m 0.1 auch umgehen ? Wenn nicht, dann ist es eher -m 0.

    Helmut


    Edit: etwas zu spät geschrieben. Es ist ja schon gelöst.

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Einmal editiert, zuletzt von HelmutB ()

    Beim ersten Versuch hatte ich 'tune2fs -m 5' gemacht, was in 24418917 resultierte, also genau dem Wert, der bereits vorlag. Dann habe ich mit 'tune2fs -r 483097' einfach fest den Wert der alten Platte gesetzt, und das führte zum gewünschten Ergebnis. Vielleicht war früher der Default ein anderer.


    Klaus

    Oder Du hattest bei der alten Platte tune2fs -m 0.1 genutzt, das passte nämlich genau:


    1. Block count: 483097296
    2. Reserved block count: 483097

    Jochen

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden