Zwei ext4-Partitionen: Gleicher Inhalt, unterschiedlicher Füllstand?!
Rolf
- linux
0 woodfighter0 Rolf
Hallo allerseits!
Zwei ext4-Partitionen stellen mich vor ein Rätsel: Es handelt sich um zwei 2-TByte-Platten, eine WD20EARS (älter, "Ziel") und eine WD20EZRX ("Quelle"). Letztere ist komplett mit einer Partition belegt, erstere hat noch eine Systempartition, die allerdings nur knapp 6 GByte belegt.
Ich habe jetzt die Daten mit cp -a auf die zuvor leere Zielplatte kopiert und hätte erwartet, dass beide Platten annähernd den gleichen Füllstand aufweisen (das Ziel ist schon als /home in Benutzung und kann sicher etwas abweichen).
Stattdessen sind auf der Zielplatte satte 67 GByte mehr belegt. Wo bitte sind die hin? Kann das jemand erklären?
Mir fallen nur kaputte Blöcke auf der Zielplatte als Erklärung ein. Aber wo finde ich eine Angabe darüber, wie viele? Verwaltungsaufwand durch Fragmentierung kann es nicht sein, die Zielplatte war leer.
df -h
Filesystem Size Used Avail Use%
/dev/sdb1 1.8T 1.7T 103G 95% Quelle
/dev/sda2 1.8T 1.7T 30G 99% Ziel
df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 1922728840 1795421904 107755420 95% Quelle
/dev/sda2 1916963992 1789160196 30404604 99% Ziel
du -bs Quelle: 1832350434469
du -bs Ziel: 1831066816899
dumpe2fs Quelle:
Filesystem UUID: a00045d9-17e9-4010-9eef-adbc2d54891a
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype 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: 122101760
Block count: 488378390
Reserved block count: 4883783
Free blocks: 31826734
Free inodes: 122060619
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 907
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Sep 11 15:24:00 2013
Last mount time: Tue Oct 13 10:52:19 2015
Last write time: Tue Oct 13 10:56:43 2015
Mount count: 87
Maximum mount count: -1
Last checked: Wed Sep 11 15:24:00 2013
Check interval: 0 (<none>)
Lifetime writes: 3400 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: 6b493a4d-ba7b-47e7-85fc-2bd4e8cef565
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0001301d
Journal start: 0
dumpe2fs Ziel
Filesystem UUID: 79f95cea-b18c-4e98-a4ab-47bc098a245a
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: 121733120
Block count: 486914048
Reserved block count: 24345702
Free blocks: 31949139
Free inodes: 121699048
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 907
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 Oct 12 20:17:17 2015
Last mount time: Wed Oct 14 09:39:21 2015
Last write time: Wed Oct 14 09:39:21 2015
Mount count: 8
Maximum mount count: -1
Last checked: Mon Oct 12 20:17:17 2015
Check interval: 0 (<none>)
Lifetime writes: 1742 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: 60e84120-6cf1-4e3a-84b9-83f90cdc9f93
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00001915
Journal start: 1
Tach,
Stattdessen sind auf der Zielplatte satte 67 GByte mehr belegt. Wo bitte sind die hin? Kann das jemand erklären?
also fangen wir an:
df Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 1922728840 1795421904 107755420 95% Quelle
/dev/sda2 1916963992 1789160196 30404604 99% Ziel
Die Quellplatte war schonmal (1922728840-1916963992)*1000 Byte ≈ 5GiB größer als die Zielplatte.
Aber der wesentliche Faktor dürften die Reserved Blocks sein (beide Platten haben 4kiB große Blöcke): 4883783 bei der Quelle (1%) und 24345702 beim Ziel (5%) und (24345702-4883783) * 4 kiB ≈ 74 GiB. Das ist soagr mehr als du suchst (vermutlich konnte das neue Dateisystem manche Dinge sparsamer ablegen als das alte). Der Wert für die Reserved Blocks ist änderbar mit tune2fs, allerdings sollte er nicht zu niedrig gesetzt werden, allerdings sind die standardmäßigen 5% bei großen Platten eher übertrieben.
mfg
Woodfighter
Hallo,
Stattdessen sind auf der Zielplatte satte 67 GByte mehr belegt. Wo bitte sind die hin? Kann das jemand erklären?
Die Quellplatte war schonmal (1922728840-1916963992)*1000 Byte ≈ 5GiB größer als die Zielplatte.
das ist die Systempartition, von der ich schrieb, die hatte ich schon rausgerechnet.
Aber der wesentliche Faktor dürften die Reserved Blocks sein (beide Platten haben 4kiB große Blöcke): 4883783 bei der Quelle (1%) und 24345702 beim Ziel (5%) und (24345702-4883783) * 4 kiB ≈ 74 GiB.
Da haben wir's, danke! Ich hatte schon irgendwie den Verdacht, dass sich die Ursache irgendwo in den Zahlen versteckt, aber das ist dann wohl ein Fall von "Den Baum vor lauter Wald nicht sehen".
Danke nochmal. Rolf