[gelöst] Unerklärliche Plattenbelegung

kls · January 27, 2019 at 1:30 PM

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

Space · January 27, 2019 at 2:07 PM

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

kls · January 27, 2019 at 2:26 PM

'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:

Erste Platte (die mit mehr freiem Platz)

Code

tune2fs 1.42.11 (09-Jul-2014)
Filesystem volume name:   VIDEO
Last mounted on:          /video
Filesystem UUID:          0422f08d-91d8-4394-9f2d-b01ebf23fe89
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:              120774656
Block count:              483097296
Reserved block count:     483097
Free blocks:              3065127
Free inodes:              120771775
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      908
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Mon Jan 30 15:16:48 2017
Last mount time:          Fri May  4 11:32:21 2018
Last write time:          Fri May  4 11:32:21 2018
Mount count:              64
Maximum mount count:      -1
Last checked:             Mon Jan 30 15:16:48 2017
Check interval:           0 (<none>)
Lifetime writes:          3365 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:      c545ce3b-3ba4-490f-8c7e-8fc777312533
Journal backup:           inode blocks

Display More

Zweite Platte (die mit weniger freiem Platz)

Code

tune2fs 1.43.8 (1-Jan-2018)
Filesystem volume name:   <none>
Last mounted on:          /video
Filesystem UUID:          2b451d82-500b-4e2b-b00b-0afc4f6f55c7
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit 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:              122101760
Block count:              488378352
Reserved block count:     24418917
Free blocks:              25435072
Free inodes:              122098768
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Jan 26 13:47:53 2019
Last mount time:          Sun Jan 27 12:53:53 2019
Last write time:          Sun Jan 27 12:53:53 2019
Mount count:              5
Maximum mount count:      -1
Last checked:             Sat Jan 26 13:47:53 2019
Check interval:           0 (<none>)
Lifetime writes:          1842 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      dee29c52-9a9e-463b-86c6-31d2399e35e9
Journal backup:           inode blocks

Display More

Klaus

Space · January 27, 2019 at 2:44 PM

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

Space · January 27, 2019 at 2:52 PM

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

kls · January 27, 2019 at 2:52 PM

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

Space · January 27, 2019 at 2:53 PM

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

Gruß,

Jogi

kls · January 27, 2019 at 3:01 PM

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

HelmutB † · January 27, 2019 at 3:09 PM

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.

kls · January 27, 2019 at 3:16 PM

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

Space · January 27, 2019 at 8:52 PM

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

Block count: 483097296
Reserved block count: 483097

Jochen

kls · January 27, 2019 at 10:48 PM

Ich bin mir sicher, dass ich das nicht gemacht habe.

Klaus

[gelöst] Unerklärliche Plattenbelegung

Participate now!

Users Viewing This Thread