ext4: Jak uwzględnić przestrzeń systemu plików?

Niedawno sformatowałem dysk 1,5 TB z zamiarem zamiany NTFS na ext4.

Potem zauważyłem, że zapisane przeze mnie pliki nie mieszczą się na nowej partycji.

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

Ta różnica 1 tys. Bloków oznacza rażące zmniejszenie powierzchni użytkowej o 22 GiB.

Już wykonałem

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

co nie powinno dziwić, ponieważ nie wpływa to na bloki, których po prostu nie ma.

Mimo to fdisk informuje, że partycja ext4 obejmuje cały dysk.

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

I tak np. Raporty resize2fs informują, że nie ma „nic do zrobienia!”

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      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:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
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 May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
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
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

Co wykorzystuje tę brakującą przestrzeń?

Zobaczmy. Rozmiar urządzenia to 1465138 583½ kB = 15003030909504 B. System plików składa się z 366 284 288 bloków po 4096 B każdy, co oznacza 1500 300 400 443 648 B. Nie wiem do czego służy pozostałe 1455856 B (1,4 MB) (dodatkowe kopie superbloku Wiem, że na początku jest kilka kilobajtów miejsca na bootloader.).

System plików zawiera 91 578 368 i-węzłów po 256 bajtów każdy, co zajmuje 23 444 062 208 B (około 22 GB, podpowiedź, podpowiedź). Następnie istnieje 1 442 146 364 kB = 1 476 757 876 736 B dla zawartości pliku. Odpowiada to 23 444 062 208 B + 1 476 757,876,736 B = 1 500,201,938,944 B. Pozostały rozmiar to 98 504,704 B = 24 029 bloków, co jest w odpowiednim zakresie, aby być rozmiarem dziennika.

Jak widać, wszystko jest rozliczane. (Ok, prawie wszystko, ale mówimy o megabajtach, a nie gigabajtach.)

Po pierwsze, różnica w dostępnej przestrzeni, którą widzisz, wcale nie oznacza, że ​​przestrzeń jest „zmarnowana”; nie jest marnowany, ponieważ ma fundamentalne znaczenie dla funkcjonowania systemu plików. Nie powinieneś porównywać Ext4 i NTFS w ten sposób bez bardzo dużego „ale” określającego wszystkie różnice konstrukcyjne i strukturalne między systemami plików, a także specyfikę każdej implementacji (np. Jak każdy sterownik zgłasza wolne miejsce w warstwie VFS).

Wyobraź sobie partycję jako ogromną przestrzeń, w której możesz umieścić dowolne posiadane dane. Jeśli masz tylko jeden kawałek danych o rozmiarze równym partycji, możesz po prostu zapisać go od początku partycji i być z nim spoko. Ale ty nie. Zamiast tego możesz mieć tysiące małych plików i wszystkie te pliki pogrupowane na różne sposoby, a każdy plik powiązany z wieloma innymi małymi fragmentami danych (nazwa, data / czas i uprawnienia) itp. Musisz zorganizować dużą przestrzeń partycjonowanie, abyś mógł szybko i skutecznie dotrzeć do tych wszystkich danych. Ponadto musisz się martwić, jak efektywnie zapisywać nowe fragmenty danych i skutecznie usuwać stare. Potrzebujesz struktur danych .

I jest wiele struktur danych . Niektóre z nich są bardzo głupie, inne umożliwiają szybsze pobieranie danych kosztem wolniejszych zapisów, inne pozwalają zapisywać szybciej kosztem odczytów, niektóre nadal mogą być bardzo dobre zarówno w odczytach, jak i zapisach, ale wymagają długich przerw i bezczynny nad głową podczas porządkowania danych itp.

Na pewno potrzebujesz systemu, który:

1. Bardzo szybko pisze o tym informacje;
2. Bardzo szybko odzyskuje z niego informacje;
3. Jest dobry w organizowaniu i zarządzaniu przechowywanymi w nim informacjami;
4. Dobrze wykorzystuje przestrzeń (partycję), w której przechowywany jest system plików;
5. Jest odporny na problemy ze sprzętem, dzięki czemu odzyskujesz większość lub wszystkie informacje z powodu częściowych awarii systemu;
6. Jest odporny na problemy z oprogramowaniem, dzięki czemu błąd w aplikacji lub zainstalowana złośliwa aplikacja nie zniszczy danych na stałe;
7. Jest odporny na błędy ludzkie, dzięki czemu wybacza ci, gdy przypadkowo nakazujesz systemowi usunięcie czegoś, czego nie powinieneś (np. Kosza / kosza).

Wysokowydajne systemy plików umożliwiają bardzo szybkie odczytywanie i zapisywanie kosztem miejsca. Niektóre z najszybszych struktur danych używanych w systemach plików, takie jak tabele skrótów i B-drzewa , są bardzo złożone i rezerwują więcej miejsca, niż jest w rzeczywistości używane, aby umożliwić bardzo szybki dostęp.

Ext4 ma inne ważne właściwości. W systemie plików nie ma pojedynczego punktu awarii. Istnieje wiele kopii krytycznych danych rozprzestrzeniających się na partycji, podczas gdy niektóre inne systemy plików (nie mogę powiedzieć o NTFS) mogą sprawić, że wszystkie twoje dane będą nieczytelne, jeśli awaria wystąpi we właściwym miejscu. Ponadto Ext4 rezerwuje dużo miejsca na twoje dane już na etapie tworzenia systemu plików, podczas gdy NTFS rośnie wraz z twoimi danymi.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

Ten komunikat wskazuje, że dysk używa partycjonowania w stylu GPT, a to fdisknarzędzie rozpoznaje tylko starszy styl MBR.

Aby zapobiec przypadkowym przekształceniom, jeśli dyski z partycjami GPT zostaną podłączone do starszych systemów nieobsługujących GPT, schemat partycjonowania GPT obejmuje „ochronny MBR”: całkowicie fałszywą tabelę partycji, która w zasadzie mówi „ten dysk jest całkowicie używany przez typ partycji nic nie wiem o ”żadnym systemie operacyjnym ani narzędziu, które rozumie tylko partycjonowanie MBR.

Aby uzyskać dokładne wyświetlanie tabeli partycji /dev/sdb, użyj:

parted /dev/sdb print