ext4 – znacznie szybsze sprawdzanie dysku!
- Dodano: 12 August 2008
- Wprowadził: kocio
- Komentarze: 40
Ted Ts’o napisał na swoim blogu, że nowy system plików dla Linuksa (nadal we wczesnym stadium rozwoju) — ext4, już wygląda interesująco. Czas sprawdzania partycji sformatowanej jako ext4 może być nawet ponad 10-krotnie krótszy niż na partycji ext3!
Te dane przytoczył za Rikiem Wheelerem, ale dokonał też własnego pomiaru, który potwierdza takie wyniki. Porównanie wykazało 7-krotne przyspieszenie pracy fsck. Co najbardziej interesujące, to fakt, że… ext4 dotąd nie było optymalizowane pod tym kątem!
Ponieważ T’so 1,5 miesiąca temu przesiadł się już całkowicie na ext4, dla celów testu utworzył partycję ext3 i przekopiował tam dane z partycji ext4. Warto zauważyć, że ext3 miał dzięki temu fory, ponieważ dane były bardziej uporządkowane.
Skracanie czasu sprawdzania dysków jest o tyle istotne, że pojemności dysków wciąż rosną. Wedle zeszłorocznych szacunków w 2013 r. sprawdzenie dysku przez fsck może wzrosnąć 7,5 do 80 minut. Wstępne wyniki ext4 sugerują, że to niekorzystne zjawisko da się opanować, a może nawet zmniejszyć jego uciążliwość.
Więcej informacji: http://tytso.livejournal.com/57711.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
40 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Sprawdzanie sprawdzaniem, ale jak bedzie z transferem danych..
a jak optymalizacja pod SSD? Połki co jedyny sensownym system plików na SSD to FAT32 i FFS, z racji braku journalingu
a co ma do tego ksiegowanie ?
Dużo. Szczególnie jeżeli dziennik znajduje się w jednym miejscu a karta pamięci nie ma takiego ficzeru co go nazywają 'wear leveling'. Dziennikowanie generuje dużą ilość zapisów w jednym miejscu – co w przypadku pamięci flash powoduje intensywne 'wypalanie się' pamięci flash w miejscu w którym umieszczony jest dziennik.
Generalnie do kart flash poleca się stosowanie filesystemów bez dziennikowania – nawet jeżeli mają wear leveling (obok pisania w jednym miejscu dziennikowany system pisze częściej po dysku, mniejszymi porcjami i synchronicznie). Jeżeli już musimy użyć filesystemu z dziennikiem, poleca się wyłączenie trybu synchronicznego pisania po dzienniku – system zaczyna wtedy 'grupować' zmiany w większe porcje i wykonuje mniejszą ilość większych zapisów.
dziwne, czyli jffs/jffs2 nie sa polecane na pamieciach flash?
nie chodzi o to by ograniczyc czestotliwosc zapisow – bardziej chodzi o wymuszenie, by kolejne zapisy nie trafialy w to samo miejsce…
btw. w przypadku coraz popularnieszych ram-ata ("dysk" w postaci bateryjnie podtrzymywanych ukladow DDRx) efekt "wypalania" nie ma miejsca.
jellonek: JFFS/JFFS2 to nie jest klasyczny dziennikowany filesystem – tam algorytm dziennikopodobny obejmuje całą przestrzeń wystawioną przez urządzenie (uwaga: nie mylić z wandering log!) i generalnie służy do przechowywania danych a nie tylko do zrobienia replay podczas montowania. Dzięki temu flash zużywa się mniej więcej równo. Aby jeszcze poprawić "przyjazność" filesystemu dla pamięci flash niektóre filesystemy uwzględniają dodatkowo wielkość sekcji flash (która dla NAND flash może wynosić np. 64kB – to dużo więcej niż wielkość bloku). Jeżeli klasyczny filesystem pisze np. 10 bloków od rząd w ramach tej samej sekcji to jest ona nadpisywana 10 razy pod rząd. Nie wiem czy JFFS/JFFS2 to stosują.
jellonek: ,,coraz popularniejszych''? Jest iRAM… i coś jeszcze? Takie kosntrukcje wciąż są o wiele droższe za GB niż SSD na flash, które ostatnio robią furorę.
są bardzo drogie, ale zapewniają bardzo dobre osiągi. jeśli masz małą bazkę (tj. poniżej 100G) takie rozwiązanie zapewnia bardzo dobre czasy dostępu, jak i cholernie małe io-waits.
boorac: dokladnie. ztcp zrodla jffs2 – stosują.
Nawet jak by księgowanie miało coś do tego, to przecież można je zazwyczaj wyłączyć.
Tworząc partycję ext3 nie można wyłączyć żurnalingu?
wowczas mamy ext2.
ext3 == ext2 + journaling
To, że jornaling na SSD jest niepotrzebny, bo czas dostępu w każdy rejon jest dysku taki sam (niema głowicy). Plus wiele innych aspektów, które były brane pod uwagę tworząc systemy plików po 1989r dla HDD.
Nie do końca ext3 = ext2 + journaling. Z ext2 da się łatwo przenieść na ext3 dodając księgowanie, ale sam ext3 posiada wiele własnych rozszerzeń zwiększających jego szybkość, ale za razem tracąc kompatybilność.
michku : to teraz doczytaj czym jest ksiegowanie.
Michku: journaling nigdy nie zwiększa wydajności filesystemu – zawsze spowalnia. Zwiększa za to bezpieczeństwo danych (lub metadanych) w wypadku utraty zasilania. Ale w przypadku klasycznego flash'a zmniejsza bezpieczeństwo danych "wypalając" flash szybciej niż filesystem bez dziennikowania.
journaling nie potrzebny na SSD? muahaha
michku: doczytaj do czego sie go stosuje…
w powyzszych komentarzach masz juz delikatne ku temu naprowadzenia…
btw. te nieuki piszace jffs2 pewnie sie nie znaja, skoro specjalnie dla pamieci flash opracowali fs bazujacy na journalingu zarowno czystych danych jak i metadanych…
boorack: Niby też jestem tak nauczony ale ….
z IBM: zerknij na Reading a 16Mb file
Jakimś przypadkiem ext3 układa ładniej dane w trybie data=journal i przy odczycie działa szybciej niż ext2
Może jeszcze logfs, kiedy wyjdzie
.
Ten Trol "michku" to pewnie Trash pod nowym nickiem, ktory nic nie wie, myli księgowanie z….hm….cachem, czy moze odczytem z wyprzedzeniem, choc w sumie obydwa tez by sensu nie mialy, ale pisac musi.
Ksiegowanie chroni dysk przed utrata danych w wypadku utraty zasilania, eico spowalnia zapis(Flash z zaozenia jest wolniejszy),to ma ograniczona liczbe zapisow, przez co journaling szybciej taki dysk sie badblockami zapychal.
Czemu od razu trol ? I dlaczego ujemna karma ??? Rzeczywiście tak jest. Właściwości kart flash mocno zmieniły warunki pracy filesystemów – w przypadku FAT ewidentne wady (brak dziennika, brak ficzerów typu pamiętanie ostatniego access time) zmieniły się w zalety. Zupełnie przypadkiem – a nie z powodu czyjejś złej woli.
Sorki za powyższy post, pomyliłem michku z janc.
moze lepiej niech sam wyjasni z czym to pomylil, bo tak na prawde ciezko samemu do tego dojsc
moze dla niego operacja zapisu np. 100 megowego pliku jest na SSD operacja atomowa? to przeciez taki szybki nosnik
Boorack, akurat access time można wyłączyć przy opcjach montowania. Fakt, że nowy system plików będzie dalej serwerowy i czas na jakiś system plików na desktopy, które poradzą sobie z laptopowymi dyskami stosowanymi obecnie i wypierającymi je SSD, które nie lubią częstych zapisów ani odczytów.
Z drugiej strony uparty użytkownik skonfiguruje sobie czytanie z wyprzedzeniem, programowe buforowanie zapisu, więc może zamiast tworzyć coś nowego dodać opcje montowania ssd która ustawi te funkcje od razu?
FAT32 nie jest sensowny – np. z powodu ograniczenia welkości plików do 4GB i wstecznej zgodności z FAT16. Ale Ext2 jest całkiem OK
Ach ci programisci, im to sie juz w dupach calkiem poprzewracalo skoro nie wynalezli systemu ssd. A powinni wynalezc.
Co do SSD polecam sobie przeczytać ten wątek:
https://lists.linux-foundation.org/pipermail/ksum…
Ja używam RaiserFS i jest oki
Miałem EXT2 a potem EXT3 i te systemy plików nieco zamulały.
Z resztą dzisiaj to już można mieć Linuxa na EXT[x] albo RaiserFS, a dane trzymać na NTFS
(trochę licho z prawami, ale poza tym nie ma problemu)
NTFS mnie nie zadowala, bo pod Linuksem nie mam narzędzi do reperacji w razie kłopotów. A bardzo by mi się przydało, np. jak reperuję cudzy komputer z MS Windows.
a virtualbox + bartpe? zartowalem
Do tego jeszcze najlepsza implementację NTFS pod Linuksa można uzyskać jedynie korzystając z FUSE. Osobiście nie sprawdzałem, ale wydaje mi się, że jest o wiele wolniejsza od sterownika w jądrze.
E, to akurat nie jest chyba problem, zaskakująco wydajne się okazało to rozwiązanie:
http://www.ntfs-3g.org/performance.html
Pomineli ile to procka zre. Probowalem tego u cioci uzyc juz na poprzednim kompie, ale to zabijalo 500MHz, i sie wywalalo nierzadko przy dluzszym obciazeniu(i niszczylo FSa). Na 2GHz dzialalo stabilnie, ale tak wolno i zarlo procka ze zwalnailo tworzenie obrazow DVD, szybszy byl naped optyczny
Te ich benchmarki sa zaklamane, tzn srtpawdzaja sie moze na dzterordzeniowych 3GHz maszynach, gdzie (w ich tescie) liczy sie predkosc, a nie zasobozernosc. Jakby dali 10 dyskowy RAID0 to pewnie zaden procek by juz nie wystarczyl
Co do reisera to nie jestem zadowolony z tego systemu plików. Koledze się pofragmentował, więc kwalifikuję go na dysk z małą ruchliwością danych.
I know I should take some of your points into consideration but sometimes we can just get lazy.. after all we are just humans.
Nothing against the article, but I disagree with a couple of points to some extenct. I’m probably a minority though, lol. Thanks for sharing.
Hi there, I found your blog via Google while searching for a related topic, your site came up, it looks good. I have bookmarked it in my google bookmarks.
After study a few of the blog posts on your website now, and I truly like your way of blogging. I bookmarked it to my bookmark website list and will be checking back soon. Pls check out my web site as well and let me know what you think.
Howdy, I just hopped over for your website online via StumbleUpon. No longer one thing I’d usually learn, but I liked your thoughts none the less. Thanks for making something price reading.
@Dan I get your drift on where you were going there. I often think of my past and use it as a means to analyze where I am and where I want to get to. Where I struggel is balancing it all out. How do you guys balance things out?
so much great information on here, : D.