Dlaczego te pliki w woluminie ext4 są pofragmentowane?


19

Mam ext4partycję 900 GB na (magnetycznym) dysku twardym, który nie ma wad i nie ma uszkodzonych sektorów. Partycja jest całkowicie pusta, z wyjątkiem pustego lost+foundkatalogu. Partycja została sformatowana przy użyciu domyślnych parametrów, tyle że ustawiłem liczbę zarezerwowanych bloków systemu plików na 1%.

Pobrałem plik ~ 900 MB xubuntu-15.04-desktop-amd64.isodo katalogu punktu instalacji partycji, używając wget. Po zakończeniu pobierania okazało się, że plik został podzielony na cztery fragmenty:

filefrag -v /media/emma/red/xubuntu-15.04-desktop-amd64.iso
Filesystem type is: ef53
File size of /media/emma/red/xubuntu-15.04-desktop-amd64.iso is 1009778688 (246528 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  246527:     264192..    287487:  23296:             eof
/media/emma/red/xubuntu-15.04-desktop-amd64.iso: 4 extents found

Sądząc wget, że może to być w jakiś sposób związane, usunąłem plik ISO z partycji, czyniąc go ponownie pustym, a następnie skopiowałem plik ~ 700 MB v1.mp4na partycję cp. Ten plik również został pofragmentowany. Został podzielony na trzy fragmenty:

filefrag -v /media/emma/red/v1.mp4
Filesystem type is: ef53
File size of /media/emma/red/v1.mp4 is 737904458 (180153 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  180152:     198656..    219064:  20409:             eof
/media/emma/red/v1.mp4: 3 extents found

Dlaczego to się dzieje? I czy istnieje sposób, aby temu zapobiec? Myślałem, że ext4ma być odporny na fragmentację. Zamiast tego stwierdzam, że natychmiast fragmentuje pojedynczy plik, gdy cała reszta woluminu nie jest używana. To wydaje się być gorsze niż oba FAT32i NTFS.


4
Próbuję sobie wyobrazić, w jakich okolicznościach może to mieć znaczenie, i wychodzę pusty.
Greg Hewgill

4
@GregHewgill: To miało znaczenie, ponieważ myślałem, że jest nienormalny. Teraz wiem, że to normalne, to nie ma znaczenia.
EmmaV,

Odpowiedzi:


17

3 lub 4 fragmenty w pliku 900mb bardzo dobre. Fragmentacja staje się problemem, gdy plik o tym rozmiarze zawiera ponad 100 fragmentów. Tłuszcz lub plik NTFS często dzielą taki plik na kilkaset kawałków.

Zasadniczo nie zobaczysz tego lepiej, przynajmniej w starszych systemach plików ext4, ponieważ maksymalny rozmiar grupy bloków wynosi 128 MB, a więc co 128 MB ciągłe miejsce jest dzielone przez kilka bloków dla bitmap alokacji i tabel i-węzłów dla następna grupa bloków. Nowsza funkcja ext4 o nazwie flex_bg umożliwia spakowanie wielu tabel (zwykle 16) grup bloków w tych tabelach, pozostawiając dłuższe serie bloków, które można alokować, ale w zależności od dystrybucji i wersji e2fsprogs użytej do jej sformatowania, ta opcja może nie były używane.

Możesz użyć tune2fs -ldo sprawdzenia funkcji włączonych podczas formatowania systemu plików.


Bardzo interesujące. Zakładałem, że wszystkie tabele i-węzłów itp. Były na początku woluminu.
EmmaV,

1
@EmmaV dystrybuując je na dysku, względnie blisko danych, do których się odnoszą, skutkuje krótszymi próbami i szybszym dostępem do dysku :)
hobbs

10

Naprawdę nie potrafię odpowiedzieć, ale myślę, że to może pomóc:

Zauważ, że każdy fragment ma maksymalnie 32768 bloków (moc 2, która powinna podnieść flagę, że coś się dzieje, a także dać wskazówkę, na co należy zwrócić uwagę).

Warto również zauważyć, że te fizyczne przesunięcia między zakresami są dość blisko siebie.

Od: Układ dysku Ext4

System plików ext4 jest podzielony na szereg grup bloków. Aby zmniejszyć problemy z wydajnością wynikające z fragmentacji, alokator bloków bardzo mocno stara się utrzymać bloki każdego pliku w tej samej grupie, co skraca czas wyszukiwania. Rozmiar grupy bloków jest określony w sb.s_blocks_per_group blocks, chociaż można go również obliczyć jako 8 * block_size_in_bytes. Przy domyślnym rozmiarze bloku 4KiB każda grupa będzie zawierała 32 768 bloków o długości 128 Mb

I dalej:

Pierwszym narzędziem używanym przez ext4 do zwalczania fragmentacji jest wieloblokowy alokator. Kiedy plik jest tworzony po raz pierwszy, alokator bloków spekulacyjnie przydziela 8KiB miejsca na dysku do pliku [...] Drugą powiązaną sztuczką używaną przez ext4 jest alokacja opóźniona. Zgodnie z tym schematem, gdy plik potrzebuje więcej bloków, aby wchłonąć zapisy, system plików odkłada decyzję o dokładnym umieszczeniu na dysku, dopóki wszystkie brudne bufory nie zostaną zapisane na dysk. Nie zobowiązując się do określonego miejsca docelowego, dopóki nie będzie to absolutnie konieczne (przekroczony zostanie limit czasu zatwierdzenia lub wywołana zostanie synchronizacja () lub w jądrze zabraknie pamięci), mamy nadzieję, że system plików będzie mógł podejmować lepsze decyzje dotyczące lokalizacji.

Powiedziałbym więc, że alokator dba tylko o lokalizację danych w grupie bloków (te bloki 32K), ale nie o to, by grupy bloków były ze sobą sąsiadujące.


Pierwszy cytat, który podałeś, odpowiada na moje pytanie.
EmmaV,

1
Każdy zasięg ma maksymalnie 32 tys. Bloków, ponieważ jest to maksymalna długość, jaką może obejmować deskryptor zasięgu. Zakresy nie są fragmentami. Jeśli zauważysz, że kilka fizycznych bloków zakresu natychmiast następuje po blokach z poprzedniego zakresu, a zatem nie stanowią fragmentu (6 zakresów w porównaniu z 3 fragmentami).
psusi
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.