Mam zwirtualizowane środowisko o bardzo dużej gęstości z kontenerami, dlatego staram się, aby każdy kontener był naprawdę mały. „Naprawdę mały” oznacza 87 MB na podstawowym Ubuntu 14.04 (Trusty Tahr) bez naruszenia kompatybilności menedżera pakietów.
Dlatego używam LVM jako miejsca do przechowywania moich pojemników, a ostatnio znalazłem bardzo dziwne liczby. Tutaj są.
Stwórzmy logiczny wolumin 100 MiB (tak, potęga 2).
sudo lvcreate -L100M -n test1 /dev/purgatory
Chciałbym sprawdzić rozmiar, więc wystawiam sudo lvs --units k
test1 purgatory -wi-a---- 102400.00k
Kochanie, to naprawdę 100 MiB.
Teraz stwórzmy system plików ext4 . I oczywiście pamiętamy -m 0parametr, który zapobiega marnowaniu przestrzeni.
sudo mkfs.ext4 -m 0 /dev/purgatory/test1
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25688 inodes, 102400 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
Słodko i czysto. Zwróć uwagę na rozmiar bloku - nasz wolumin logiczny jest mały, więc mkfs.ext4 postanowił stworzyć blok o wielkości 1 KiB, a nie zwykły 4 KiB.
Teraz go zamontujemy.
sudo mount /dev/purgatory/test1 /mnt/test1
I zadzwońmy dfbez parametrów (chcielibyśmy zobaczyć 1 blok KiB)
/dev/mapper/purgatory-test1 95054 1550 91456 2% /mnt/test1
Zaczekaj, o cholera ~
Łącznie mamy 95054 bloków. Ale samo urządzenie ma 102400 bloków 1 KiB. Mamy tylko 92,8% naszego magazynu. Gdzie są moje bloki, stary?
Spójrzmy na to na prawdziwym urządzeniu blokowym. A ma dysk wirtualny 16 GiB, 16777216 bloków 1K, ale tylko 15396784 bloków jest w formacie df. 91,7%, co to jest?
Teraz następuje śledztwo (spoiler: brak wyników)
System plików nie może rozpocząć się na początku urządzenia. To dziwne, ale możliwe. Na szczęście ext4 ma bajty magiczne, sprawdźmy ich obecność.
sudo hexdump -C / dev / purgatory / test1 | grep „53 ef”
To pokazuje superblok:
00000430 a9 10 e7 54 01 00 ff ff 53 ef 01 00 01 00 00 00 |...T....S.......|
Heks 430 = 1072 grudnia, więc gdzieś po pierwszym kilobajcie. Wygląda rozsądnie, ext4 pomija pierwsze 1024 bajty w przypadku takich osobliwości, jak VBR itp.
- To jest dziennik!
Nie, nie jest. Dziennik zabiera miejsce z Dostępne, jeśli wyjście df.
- Och, mamy dump2fs i możemy sprawdzić tam rozmiary!
... dużo greps ...
sudo dumpe2fs /dev/purgatory/test1 | grep "Free blocks"
Ojej.
Free blocks: 93504
Free blocks: 3510-8192
Free blocks: 8451-16384
Free blocks: 16385-24576
Free blocks: 24835-32768
Free blocks: 32769-40960
Free blocks: 41219-49152
Free blocks: 53249-57344
Free blocks: 57603-65536
Free blocks: 65537-73728
Free blocks: 73987-81920
Free blocks: 81921-90112
Free blocks: 90113-98304
Free blocks: 98305-102399
I mamy inny numer. 93504 wolnych bloków.
Pytanie brzmi: co się dzieje?
- Zablokuj urządzenie: 102400k (lvs mówi)
- Rozmiar systemu plików: 95054k (mówi df)
- Darmowe bloki: 93504k (mówi dumpe2fs)
- Dostępny rozmiar: 91456 k (mówi df)
ext2do małych partycji.ext2wygląda tutaj rozsądnie, pewnieOdpowiedzi:
Spróbuj tego:
mkfs.ext4 -N 104 -m0 -O ^has_journal,^resize_inode /dev/purgatory/test1Myślę, że to pozwala zrozumieć „co się dzieje”.
-N 104(ustaw liczbę iNodes, które powinien mieć system plików)-m 0(bez zarezerwowanych bloków)-O ^has_journal,^resize_inode(dezaktywuj funkcjehas_journaliresize_inoderesize_inode„kosztuje” wolne miejsce (większość z 1550 bloków 1K / 2%, które widzisz w swoimdf- 12K jest wykorzystywana do folderu „utracone + znalezione”)has_journal„kosztuje” powierzchnię użytkową (4096 bloków 1K w twoim przypadku)Wydostajemy
102348się102400, kolejne 52 bloki są bezużyteczne (jeśli usunęliśmy folder „lost + found”). Dlatego nurkujemy wdumpe2fs:i policz używane bloki (w przypadku superbloku kopii zapasowej, deskryptorów grup, mapy bitowej bloku, mapy bitowej Inode i tabeli Inode) lub my
grepi policz:co daje nam liczbę linii, które mają pojedynczy blok (w naszym przykładzie) i
co daje nam liczbę linii, które mają dwa bloki (w naszym przykładzie).
Mamy więc (w naszym przykładzie)
13linie z jednym blokiem każdy i19linie z dwoma blokami każdy.co daje nam
51bloki, które są używane przez sam ext4. Wreszcie został tylko jeden blok. Blok 0, czyli pomijane1024bajty na początku dla rzeczy takich jak sektor rozruchowy.źródło
dfna fs z dziennikiem: 95054k -dfna fs bez jorunal 99150k - i nie mieszaj „użytecznej” i „wolnej” przestrzeni.mkfs.xfs -l size=512 -d agcount=1stworzy system plików z absolutnie minimalnym rozmiarem dziennika (inaczej dziennika), ale wydajność zapisu może się pogorszyć. Nie sądzę, aby obsługa kodu XFS działała bez dziennika. Prawdopodobnie tylko do odczytu, aby obsłużyć przypadki, w których uszkodzone jest zewnętrzne urządzenie rejestrujące. (równieżagcount=1jest prawdopodobnie kolejnym strasznym pomysłem na wydajność zapisu, zwłaszcza równoległym. A nagłówki grup alokacji są prawdopodobnie również małe.)mkfs.xfs -d agcount=1na partycji 100 MB udostępniono FS 95980kiB, przy użyciu 5196k, dostępnych 90784k. Domyślne konto to 4, a domyślny rozmiar dziennika to 1605 bloków (również minimalny). Tak więc XFS używa tak małego logu, jaki pozwala ci określić, dla małych FS.Krótka odpowiedź:
Nie cała przestrzeń na urządzeniu blokowym staje się dostępną przestrzenią dla twoich danych: część surowego miejsca jest potrzebna na elementy wewnętrzne systemu plików, księgowość za kulisami.
Ta księgowość obejmuje superblok, deskryptory grup bloków, mapy bitowe bloków i i-węzłów oraz tabelę i-węzłów. Ponadto w wielu lokalizacjach tworzone są kopie superbloku do celów tworzenia kopii zapasowych / odzyskiwania. Długie informacje na temat wewnętrznych elementów systemu plików EXT4 można znaleźć na stronie ext4.wiki.kernel.org .
Ponieważ EXT4 jest kronikowanym systemem plików, który również zajmuje trochę miejsca.
Dodatkowo część miejsca jest zarezerwowana na przyszłe rozszerzenia systemu plików.
Długa odpowiedź:
Odtworzyłem Twój scenariusz na jednym z moich systemów testowych:
Następnie, nawet przed zamontowaniem systemu plików,
dumpe2fspokazuje:a po montażu:
Co więc
dfnam pokazuje? Z 102400 bloków surowego urządzenia pamięci masowej 99150 bloków 1K jest widocznych dla systemu plików, co oznacza, że 3250 1-kilobajtowych bloków surowego miejsca do przechowywania stało się bezużyteczne do faktycznego przechowywania danych.Gdzie się podziały te bloki? Przewijanie w dół
dumpe2fswyników pokazuje dokładnie, gdzie:1 block(blok # 0) Pierwsze 1024 bajty są pomijane, aby umożliwić instalację sektorów rozruchowych x86 i innych osobliwości.1 blockjest zajęty przez główny super blok.1 blockzawiera deskryptory grupy.256 blockssą zarezerwowane dla tabeli deskryptorów grupy, aby umożliwić przyszłą zmianę rozmiaru systemu plików.16 blockssą przypisane do bitmapy blokowej.16 blockssą przypisane do bitmapy i-węzłowej.246 blockssą przypisane do tabeli i-węzłów.To już stanowi 537 z 3250 brakujących bloków. System plików ext4 jest podzielony na szereg grup bloków, a przewijanie w dół pokazuje podobny przydział surowej pojemności pamięci do wewnętrznych elementów systemu plików w innych grupach bloków:
Teraz wróć do
dfwyjścia:Powodem, dla którego w tym nowym systemie plików jest już zaznaczone 7% pojemności jako w użyciu, jest:
99150 (rozmiar systemu plików) MINUS 5120 (liczba zarezerwowanych bloków) MINUS 5646 (zużyte bloki, z których 4096 pochodzi z dziennika (ponownie część danych wyjściowych dumpe2fs))
= 88384
Ilość wolnych bloków w dumpe2fs jest dostępnym rozmiarem systemu plików minus faktyczne użycie (i nie bierze pod uwagę zarezerwowanych bloków), więc 99150 - 5646 = 93504.
źródło
Brak odpowiedzi na pytanie, ale zainteresowałem się, więc wyobrażam sobie, że inni to zrobią. Ponieważ miałem już bootowany liveCD i miałem twardy dysk, z którym mogłem zadzierać, nie martwiąc się, że literówki mogą coś uszkodzić, poszedłem do przodu i przetestowałem.
Zrobiłem partycje ze wszystkimi FSami, dla których Ubuntu 14.10 dostarcza mkfs, na partycjach 100 MB. (z wyjątkiem minix, który obsługuje tylko 64MiB i bfs, co jest rzeczą SCO, o której nigdy nie słyszałem.)
Najpierw spojrzałem na
df -kdostępną przestrzeń (z domyślnymi ustawieniami mkfs), a następnieddprzeszedłem/dev/zerodo pliku na każdym FS, aby upewnić się, że można je całkowicie wypełnić. (tj. sprawdź, czy roszczenieavailable spacebyło naprawdę dostępne).for i in /media/ubuntu/small-*;do sudo dd if=/dev/zero of="$i/fill" bs=16k;doneDlaczego btrfs ma tyle niepotrzebnego miejsca? Może dla metadanych? no nie:
Oba systemy plików oparte na drzewach nie mogą nigdzie spakować pustego pliku, ale wszystkie inne potrafią.
Lub po prostu zobacz, jak duży plik możesz utworzyć:
(Nazywałem moją partycję ext4 „small-ext”, ponieważ nie planowałem wariować i tworzyć każdego systemu plików. Więc tutaj ext = ext4. NIE oryginalna wersja ext-ext2).
I
df -kwyjdź po ich usunięciu:(jfs wrócił do 1% wykorzystanego po tym, jak usunąłem również „dotknięty”. Albo było opóźnienie, albo trzeba było innego zapisu, aby uzyskać dostępną wielkość do aktualizacji.)
W każdym razie myślę, że o to chodzi z mojej ciekawości.
źródło