JakiLinux
Wśród ludzi używających Linuksa pokutuje mit „linuksowe systemy plików nie podlegają fragmentacji”. Ten mit można obalić za pomocą bardzo prostego skryptu, który tworzy zadaną liczbę katalogów i w każdym z tych katalogów tworzy i usuwa określoną ilość plików – w powiedzmy dwóch przebiegach.
(!!!UWAGA!!! W artykule do sprawdzania stopnia fragmentacji systemu plików używany jest program fsck.ext3 – przed użyciem tego programu na własną rękę należy się koniecznie zapoznać z jego dokumentacją. Nieumiejętne użycie fsck na zamontowanym systemie plików może się skończyć utratą danych. !!!UWAGA!!!)
Przeprowadźmy eksperyment – zaczniemy od utworzenia obrazu systemu plików
dd if=/dev/zero of=systemplikow.img bs=256M count=1Następnie utworzymy nowy system plików (proponuję ext2 lub 3, ponieważ łatwo jest uzyskać informacje o stopniu fragmentacji systemu plików)
/sbin/mkfs.ext3 systemplikow.img
Teraz możemy sprawdzić stopień fragmentacji nowo utworzonego systemu plików
/sbin/fsck.ext3 -nfv systemplikow.img
e2fsck 1.40.4 (31-Dec-2007)
Przebieg 1: Sprawdzanie i-węzłów, bloków i rozmiarów
Przebieg 2: Sprawdzanie struktury katalogów
Przebieg 3: Sprawdzanie łączności katalogów
Przebieg 4: Sprawdzanie liczników odwołań
Przebieg 5: Sprawdzanie sumarycznych informacji o grupach
11 inodes used (0.02%)
1 non-contiguous inode (9.1%)
liczba i-węzłów z blokami ind/dind/tind: 0/0/0
18561 blocks used (7.08%)
0 bad blocks
0 large files
0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
2 files
Informacje o stopniu fragmentacji zawiera linijka
1 non-contiguous inode (9.1%)
Tak sytuacja wygląda na „świeżym” systemie plików. Jak może wyglądać sytuacja na często używanym systemie plików (na którym usuwamy i zapisujemy nowe pliki), możemy się przekonać po użyciu skryptu frag.sh
Wystarczy zamontować testowy obraz systemu plików
mount -o loop systemplikow.img /mnt/loop0/
następnie podać skryptowi katalog, w którym jest zamontowany obraz systemu plików
frag.sh /mnt/loop0/
Skrypt wyrzuci wiele komunikatów w stylu
Creating file /mnt/loop0//8/file-128
28444+0 przeczytanych recordów
28444+0 zapisanych recordów
skopiowane 85332 bajty (85 kB), 0,173525 s, 492 kB/s
step = 6
Deleting file /mnt/loop0//8/file-0
Następnie odmontowujemy nasz testowy system plików
umount /mnt/loop0/
i ponownie sprawdzamy stopień fragmentacji
/sbin/fsck.ext3 -nfv systemplikow.img
Ponieważ skrypt tworzy pliki o losowym rozmiarze i usuwa losowo wybrane pliki, dane mogą się znacznie różnić od tych poniżej
e2fsck 1.40.4 (31-Dec-2007)
Przebieg 1: Sprawdzanie i-węzłów, bloków i rozmiarów
Przebieg 2: Sprawdzanie struktury katalogów
Przebieg 3: Sprawdzanie łączności katalogów
Przebieg 4: Sprawdzanie liczników odwołań
Przebieg 5: Sprawdzanie sumarycznych informacji o grupach
895 inodes used (1.37%)
315 non-contiguous inodes (35.2%)
liczba i-węzłów z blokami ind/dind/tind: 753/0/0
77202 blocks used (29.45%)
0 bad blocks
0 large files
875 regular files
11 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
886 files
Jak widać – 35.2% i-węzłów nie jest rozmieszczonych w sposób ciągły – stopień fragmentacji plików na obrazie jest bardzo duży.
Aby mieć punkt odniesienia dla dalszych eksperymentów, proponuję zrobić kopię zapasową obrazu
cp systemplikow.img systemplikow-kopia.img
Program ok_defrag możemy pobrać pod adresem
Do poprawnego działania programu jest wymagany pakiet python-dialog.
Zasada działania programu oparta jest na tej zaprezentowanej w defrag Cona Kolivasa – ok_defrag nie grzebie w strukturach danych systemu plików, tak jak to robią profesjonalne programy vide Diskeeper czy Defrag z Windows.
Program uruchamiamy w następujący sposób
ok_defrag -l log.txt -d /mnt/loop0/
Flagi -l i -d są obowiązkowe. Logowanie działań programu pozwoli nam na odzyskanie danych, gdyby coś poszło nie tak, np. gdyby został wyłączony prąd ;). Flagą -d wskazujemy katalog, gdzie znajdują się dane, które chcemy defragmentować.
Na początku ok_defrag tworzy listę katalogów znajdujących się we wskazanym katalogu – lista jest posortowana według rozmiaru katalogu – od największego do najmniejszego. Następnie dla każdego katalogu z listy tworzona jest lista plików, które się w nim znajdują – również posortowana od największego do najmniejszego. Taka metoda sortowania plików powinna przynieść najlepsze efekty podczas defragmentacji.
Każdy z plików jest kopiowany do pliku /tmp/ok_defrag_tmp, a następnie zawartość pliku /tmp/ok_defrag_tmp jest przenoszona do oryginalnego pliku – taka prosta metoda powtórzona kilkukrotnie dla każdego pliku (domyślnie 3 razy) powinna przynieść pożądany efekt. Zobaczmy jak to działa w praktyce.
Montujemy nasz testowy system plików
sudo mount -o loop systemplikow.img /mnt/loop0/
uruchamiamy ok_defrag
ok_defrag -l log.txt -d /mnt/loop0/
Teraz wystarczy trochę poczekać (!!!UWAGA!!! Procesu defragmentacji nie należy przerywać !!!UWAGA!!!)… Gdy proces się zakończy, możemy odmontować system plików
umount /mnt/loop0/
i sprawdzić rezultat
/sbin/fsck.ext3 -nfv systemplikow.img
e2fsck 1.40.4 (31-Dec-2007)
Przebieg 1: Sprawdzanie i-węzłów, bloków i rozmiarów
Przebieg 2: Sprawdzanie struktury katalogów
Przebieg 3: Sprawdzanie łączności katalogów
Przebieg 4: Sprawdzanie liczników odwołań
Przebieg 5: Sprawdzanie sumarycznych informacji o grupach
895 inodes used (1.37%)
84 non-contiguous inodes (9.4%)
liczba i-węzłów z blokami ind/dind/tind: 753/0/0
77202 blocks used (29.45%)
0 bad blocks
0 large files
875 regular files
11 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
886 files
Z 35.2% udało się zejść do 9.4%. Ponowne uruchomienie procesu powinno zmniejszyć stopień fragmentacji. Zamiast kilkukrotnego uruchamiania ok_defrag można dodać flagę -f do linii poleceń programu – wtedy proces defragmentacji będzie powtórzony zadaną ilość razy.
W przeciwieństwie do wspomnianego wcześniej defrag Cona Kolivasa, ok_defrag podchodzi bardzo paranoidalnie do bezpieczeństwa danych. Każda operacja defragmentacji podzielona jest na następujące etapy:
- zapisanie czasu ostatniej modyfikacji pliku
- zapisanie sumy kontrolnej pliku
- skopiowanie pliku do /tmp/ok_defrag_tmp
- sprawdzenie sumy kontrolnej pliku /tmp/ok_defrag_tmp
- porównanie obu sum kontrolnych – jeśli są różne, to oznacza jakieś kłopoty ze sprzętem lub systemem – defragmentacja jest przerywana dla tego pliku
- ponowne sprawdzenie czasu modyfikacji oryginalnego pliku – jeśli został zmodyfikowany po wykonaniu kopii, to defragmentacja zostaje przerwana dla tego pliku
- jeśli wszystkie powyższe etapy zakończyły się pomyślnie, to zawartość pliku /tmp/ok_defrag_tmp jest przenoszona do pliku oryginalnego
- ponowne sprawdzenie sumy kontrolnej pliku – jeśli jest różna od oryginalnej, to oznacza, że coś poszło naprawdę nie tak jak trzeba – działanie programu zostaje przerwane
Uważny użytkownik zauważy, że w siódmym etapie podczas przenoszenia zawartości /tmp/ok_defrag_tmp do oryginalnego pliku, nie jest on blokowany do zapisu dla innych programów. Jest to wada, którą mam nadzieję uda się jakoś wyeliminować, ponieważ uniemożliwia ona defragmentacje w katalogach, w których cały czas zapisywane są dane np. logi.
Gdyby coś poszło nie tak podczas defragmentacji danych, np. nagły zanik prądu – należy wykonać fsck na systemie plików. Systemy plików wyposażone w księgowanie powinny poradzić sobie z tym problemem – w końcu ok_defrag nie robi żadnych czarów-marów, tylko przenosi pliki.
Jeśli jednak plik został uszkodzony, należy zajrzeć do loga – znajdują się w nim informacje o wykonywanych zadaniach oraz sumy kontrolne plików z poszczególnych etapów.
Checking /mnt/loop0/8/file-91 md5sum
md5sum = b8b828bda1b12173f8f8b0b87d8cd872
Copying /mnt/loop0/8/file-91 to /tmp/ok_defrag_tmp
Done.
Checking /tmp/ok_defrag_tmp md5sum
md5sum = b8b828bda1b12173f8f8b0b87d8cd872
Moving /tmp/ok_defrag_tmp to /mnt/loop0/8/file-91
Done.
Checking /mnt/loop0/8/file-91 md5sum
md5sum = b8b828bda1b12173f8f8b0b87d8cd872
Jeśli np. log urywa się w momencie „Moving /tmp/ok_defrag_tmp to /foo/bar/bas” oznacza to, że plik nie został do końca przeniesiony – jego kopia znajduje się w /tmp/ok_defrag_tmp – wystarczy go podmienić.
Niektóre systemy mają funkcję usuwania plików znajdujących się w /tmp podczas startu – na czas defragmentacji najlepiej jest ją wyłączyć.
Do sprawdzenia efektów defragmentacji najlepiej jest użyć programu seekwatcher (wymaga blktrace, CONFIG_BLK_DEV_IO_TRACE i CONFIG_DEBUG_FS w jądrze systemu oraz python-matplotlib z zależnościami)
Prosty test
seekwatcher -t find.trace -o find.png -p
'sync; echo 1 > /proc/sys/vm/drop_caches; for file in `find /mnt/loop0/ \\
-type f`; do cat $file > /dev/null; done '
-d /dev/<dysk na którym znajdują się obrazy systemów plików>
pokazuje różnicę szybkości odczytu danych pomiędzy niezdefragmentowanym systemem plików (systemplikow-kopia.img)
a systemem plików poddanym operacji defragmentacji (systemplikow.img)
Operacje defragmentacji katalogów, w których system może zapisywać dane, zalecam przeprowadzać po uruchomieniu systemu do /bin/sh – parametr init=/bin/sh w linii poleceń jądra systemu. To powinno zagwarantować bezproblemowe przeprowadzenie tej operacji bez obawy o jakąkolwiek utratę danych.
Kiedy nie warto przeprowadzać defragmentacji? Jeśli fsck zwraca non-contiguous inode poniżej 10%.
Ile trwa operacja defragmentacji? Zależy od szybkości dysku, ilości i rozmiaru plików – każdy z plików jest kilkukrotnie kopiowany i przenoszony, więc ta operacja może trwać i trwać ;)
Na koniec muszę jeszcze wspomnieć o jednym – warto sprawdzić, ile mamy wolnej przestrzeni na /tmp – brak wolnego miejsca nie spowoduje uszkodzenia plików – sumy kontrolne są sprawdzane cały czas. Również na dysku, który jest poddawany defragmentacji powinna być odpowiednia ilość wolnej przestrzeni.
Co ten artykuł ma pokazać? Że faktycznie się da? Albo jest on napisany tendencyjnie albo autor nie bardzo wie co robi.
Moje uwagi:
1. Nigdzie nie jest napisane że Uniksowe systemy plików nie ulegają *w ogóle* fragmentacji – ulegają ale bardzo małej która jest pomijalna jeżeli chodzi o wydajnośc systemu plików i wcale nie wymaga defragmentacji.
2. Żeby utrzymać fragmentację na niskim poziomie nie należy zapełniać systemu plików więcej niż 90%.
3. Wielkość systemu plików użyta do testów (256MB) jest śmieszna i albo wynika z niewiedzy albo jest użyta specjalnie by pokazać fragmentację.
4. Wielkość początkowa fragmentacji (9.1%) odnosi się do pofragmentowanych i-nodów względem wszystkich użytych (11) i nijak ma się do rzeczywistości, końcowy wynik (32,5%) wynika z małej wielkości użytego systemu plików.
Generalnie pokazany test nijak ma się do rzeczywistości bo nikt nie używa tak małych systemów plików w dzisiejszych czasach. Dodam jeszcze tylko tylę że przez 8 lat używania Uniksowych systemów plików – głównie Ext3/ReiserFS nigdy nie udało mi się przekroczyć 10% poziomu fragmentacji – oczywiście przy normalnym używaniu systemu plików, nie przez jakiś sztuczny test.
Dla potwierdzenia, żeby nie było że opowiadam głupoty polecam wykonanie testu na partycji o wielkości np. 2048MB. U mnie wynik po uruchomieniu tego skryptu wyniósł 9.8%.
PS. Link do skryptu jest błędny.
"Dla potwierdzenia, żeby nie było że opowiadam głupoty polecam wykonanie testu na partycji o wielkości np. 2048MB. U mnie wynik po uruchomieniu tego skryptu wyniósł 9.8%."
Zwiększ rozmiar plików – trzymajmy się skali – ten test został dostosowany do mniejszej partycji.
"PS. Link do skryptu jest błędny."
Poprawiłem, dzięki za zwrócenie uwagi.
Ale chwilunia, wielkości plików mają odźwierciedlać normalne użytkowanie systemu plików czy tylko mają wykazać fragmentację? Bo jeżeli to drugie to tak jak pisałem zawsze da się dobrać taką wartość która ją wykaże tylko tyle że takie testy nie mają sensu bo nie obrazują prawdziwego wykorzystania systemu plików.
Zwiększać można w nieskończoność wyniki będą takie same bo zachowujemy proporcję wielkośc systemu plików/wielkośc pliku a nie o to w tym wszystkim chodzi.
"Bo jeżeli to drugie to tak jak pisałem zawsze da się dobrać taką wartość która ją wykaże tylko tyle że takie testy nie mają sensu bo nie obrazują prawdziwego wykorzystania systemu plików."
Ehhhhh…. Ten eksperyment miał wykazać, że zachodzi coś takiego jak fragmentacja.
"Zwiększać można w nieskończoność wyniki będą takie same bo zachowujemy proporcję wielkośc systemu plików/wielkośc pliku a nie o to w tym wszystkim chodzi."
No i tutaj chyba zasadniczo się różnimy podejściem. Jeśli udało mi się wykazać, że fragmentacje plików można tak łatwo wywołać, to postanowiłem się przyjrzeć problemowi i coś na niego poradzić.
Ty starasz się za to podważać wyniki eksperymentu – to akurat jest naprawdę mało ważne. Przyjrzyj się ok_defrag i spróbuj znaleźć jakiś problem związany z tym narzędziem.
Bo nie ma możliwości by ta fragmentacja nie zachodziła, bo jak zmieścisz plik wielkości 5MB mając do dyspozycji dwa obszary 2MB i 4MB w różnych miejscach nie dzieląc go.
Ogólnie cała dyskusja wynika z jednego zdania
#v+
"Wśród ludzi używających Linuksa pokutuje mit “linuksowe systemy plików nie podlegają fragmentacji”
#v-
Nie panuje mit że Linuksowe systemy plików nie podlegają fragmentacji, tylko fakt że owe systemy plików podlegają znikomej fragmentacji.
"
Nie panuje mit że Linuksowe systemy plików nie podlegają fragmentacji, tylko fakt że owe systemy plików podlegają znikomej fragmentacji"
No, mógłbym Ci udowodnić, że tak nie jest, ale pewnie będziesz się czepiał, że tak się nie używa systemu plików etc…
Myślę, że się nie zgodzimy w kwestiach fundamentalnych, więc dalsza rozmowa jest tylko stratą czasu.
Ale ja tu mówię tylko o tym niby micie. To nie jest żadna ściema tylko fakt – że Uniksowe systemy plików podlegają znikomej fragmentacji.
"1. Nigdzie nie jest napisane że Uniksowe systemy plików nie ulegają *w ogóle* fragmentacji – ulegają ale bardzo małej która jest pomijalna jeżeli chodzi o wydajnośc systemu plików i wcale nie wymaga defragmentacji."
No właśnie "ale bardzo małej która jest pomijalna" – czyli tak jakby nie ulegały ;)
"2. Żeby utrzymać fragmentację na niskim poziomie nie należy zapełniać systemu plików więcej niż 90%."
Niekoniecznie – skrypt frag nie wypełnia nawet tak małej testowej partycji w 90%.
"3. Wielkość systemu plików użyta do testów (256MB) jest śmieszna i albo wynika z niewiedzy albo jest użyta specjalnie by pokazać fragmentację."
Zaręczam Ci, że fragmentacje mógłbym Ci pokazać nawet na 2 TB systemie plików – wymagałoby to tylko więcej czasu. Mały rozmiar partycji nie był wynikiem złej woli.
"końcowy wynik (32,5%) wynika z małej wielkości użytego systemu plików."
Jak już wspomniałem, taki wynik można odtworzyć na większym systemie plików – wystarczy odpowiednio zmienić rozmiar plików w skrypcie frag.
"Dodam jeszcze tylko tylę że przez 8 lat używania Uniksowych systemów plików – głównie Ext3/ReiserFS nigdy nie udało mi się przekroczyć 10% poziomu fragmentacji"
Dodam tylko, że już prawie 10 lat używam linuksowych systemów plików i na niejednym systemie plików widziałem wyniki powyżej 10%.
"oczywiście przy normalnym używaniu systemu plików, nie przez jakiś sztuczny test."
Przeanalizuj kod – ten test tworzy pliki, następnie kasuje losowo wybrane, następnie tworzy nowe – takie zachowanie możesz zaobserwować na wielu systemach, nie ma w nim nic sztucznego.
Gdybyś odpowiednio zwiększył rozmiar plików, to bez problemu uzyskałbyś fragmentacje też na większych systemach plików.
Pomijalna – w sensie że nie ma co zaprzątać sobie nią głowy.
Oczywiście że da się bo nie ma innej możliwości wepchnięcia pliku w fragmentach jeżeli nie ma wolnego ciągłego obszaru na którym mógłby sie zmieścić.
Na 2TB musiałbyś tworzyć pliki gigantycznych rozmiarów żeby uzyskać stopień defragmentacji warty poświęcenia mu uwagi. Po co ktoś ma czytać artykuł, zaprzatać sobie głowę fragmentacją skoro przeważnie chce się ją osiągnąć tylko dla "chcenia" lub dlatego "bo można", wszystko można – pytanie tylko po co? Pokazane zjawisko prawie w ogóle nie wystepuje przy normalnym użytkownaniu systemu plików a na pewno nie rzędu >30% (co np. przy NTFS dzieje się po 3 miesięcznym używaniu systemowej partycji zapełnionej w 50%).
Ile powyżej 10% widziałeś fragmentację i na jakim systemie plików.
Mówiąc sztuczny test miałem na myśli całość artykułu w którym dobrane parametry partycji, wielkości plików itd. nijak mają się do normalnego użytkownania systemu plików.
"Mówiąc sztuczny test miałem na myśli całość artykułu w którym dobrane parametry partycji"
Nie chciałem, żeby odtworzenie warunków testów trwało więcej niż kilkanaście minut. Już widzę te reakcje czytelników – "Co? Najpierw musimy przez miesiąc codziennie tworzyć 20 plików, później losowe kasować?".
"wielkości plików itd."
Wielkość plików jest tak dobrana, żeby w dwóch cyklach – zapis, kasowanie losowych plików, ujawniła się fragmentacja.
"nijak mają się do normalnego użytkownania systemu plików."
Jak napisałem jest to eksperyment, który miał pokazać, że fragmentacja występuje. Jeśli na swoich systemach plików zapisujesz tylko kilka plików dziennie i prawie w ogóle ich nie usuwasz, to o fragmentacji możesz zapomnieć. Jednak jeśli masz serwer plików, na którym dane są zapisywane i usuwane przez osiem godzin dziennie, to bardzo szybko może dojść do dużej fragmentacji.
Proponuję następnym razem trochę przemyśleć zastosowaną procedurę testową i wyniki – pokazałem, że na Linuksowych systemach plików fragmentacja występuje, i mogę to pokazać w każdej skali. Proponuje następnym razem nie zarzucać nierzetelności "Albo jest on napisany tendencyjnie albo autor nie bardzo wie co robi.", ponieważ to dziwnie wygląda – takie zaelotowskie "Linux jest najlepszy", jeśli ktoś potrafi udowodnić, że jest trochę inaczej, to na pewno wysłannik MS i trzeba go zniszczyć, podważyć wiarygodność etc.
Wielkość plików w ogóle nie jest dobrana bo jest to N z przedziału 0-32767 i zapisywane pliki mają wielkość (N%8)*N bajtów czyli maksymalnie ok. 220KB, brakuje tu plików po kilka, kilkanaście MB a i kilkaset (cały czas mówię o realnym używaniu).
Fragmentacja występuje wszędzie i nie da się jej uniknąć z prostego powodu który opisałem komentarz wyżej. Tak samo pisałem że zawsze można ją wykazać przy każdej wielkości systemu plików – pytanie po co skoro nieodzwierciedla prawdziwego wykorzystania systemu plików.
Zarzucam bo tak to wygląda, co z tego że da się uzyskać skoro normalnie takie przypadki nie występują. Nie wywyższam tutaj Linuksa ani nie ganię MS bo akurat Twój test prawie niczego nie udowadnia w tej materii. A jeżeli chodzi o porównanie Unix/Linux/MS to najprostszy test jest taki:
1. zainstalować dystrybucję Linuksa na partycji 20GB (nawet z katalogiem domowym), używać w normalny sposób 3 miesiące (instalować oprogramowanie, zapisywać pliki, kasować itd),
2. zainstalować Windows XP na NTFS 20GB, używać tak jak Linuksa.
Na koniec porównać fragmentację obu systemów plików – z wieloletnich obserwacji w codziennym używaniu będzie to dla Linuksa ~10%, dla Windowsa ~35%.
"po co skoro nieodzwierciedla prawdziwego wykorzystania systemu plików."
A dlaczego nie? Skąd wiesz do czego ludzie wykorzystują swoje FS'y?
Czy w instrukcjach obsługi FS'ów są zwroty w stylu "Nie możesz tworzyć i usuwać wielu plików, bo to prowadzi do fragmentacji i nie jest uważane za prawdziwe wykorzystanie systemu plików".
Jeśli Tobie nie udało się doprowadzić do fragmentacji większej niż 10%, to nie oznacza, że innym się to nie udaje.
Mi nie chodzi o magiczne 10% bo równie dobrze może to i być chwilowo 15%, cały czas chodzi mi o to że uniksowe systemu plików podlegają bardzo małej fragmentacji która w 99% nie wymaga zwracania na nią uwagi, nigdy nie potrzebowałem defragmentować systemu plików pod żadnym Uniksem i nie doskwierało mi owe 10%, co innego np. NTFS.
Jeśli można:
Nikt, poza fanboyami, nie zaprzecza, że na Linuksie występuje frangementacja. Tylko, że, jak kolega wpsomniał, w domowych używaniu wyniki są takie, że można je pominąć (i to, zgodnie z prawdą, jest już wspominane). Natomiast ludzie zajmujący się systemami gdzie fragmentacja na wysokim poziomie zachodzi raczej zdają sobie z tego sprawę ;)
artykuł taki sobie. powiedziałbym że napisał go absolwent uniwersytetu, argumenty Artura przemawiają do mojej duszy absolwenta polibudy – liczy się praktyka.
Autor artykułu powinien zacząć od opisania specyfiki pracy systemów plików, jak są umieszczane pliki i jak to się dzieje że mimo teoretycznej podatności na fragmentację ta nie występuje w rzeczywistych zastosowaniach na ext3, Reiser*.
A teraz anegdota opowiedziana przez mojego profesora matematyki z polibudy: przeprowadzono eksperyment z nowym silnikiem i przy pewnych obrotach silnik wchodził w drgania. Napisał on równanie różniczkowe którego wynik miał dać odpowiedz: jak wyeliminować drgania. Niestety, nie potrafił go rozwiązać. Dał to równanie swojej kuzynce – profesor matematyki z Uniwersytetu. W laboratorium zastosowano dodatkowe podkładki gumowe które wyeliminowały drgania. Po miesiącu kuzynka przysłała odpowiedz: na kilku stronach napisała dowód matematyczny że zadane równanie ma rozwiązanie. Ale również nie potrafiła go wyznaczyć.
Pozdrawiam
"nie występuje w rzeczywistych zastosowaniach"
Problem w tym, że gdyby nie występowała, to nie zawracałbym sobie głowy pisaniem tego wszystkiego ;)
Fakt, możliwe, że nie jestem przeciętnym użytkownikiem systemu plików i u mnie fragmentacja występuje częściej niż u innych. Ale to, że u innych występuje rzadziej, nie oznacza, że wcale nie występuje. Skrypt frag w prosty sposób do niej doprowadza.
No dobra to od innej strony, w jakich scenariuszach wg. Ciebie występuje fragmentacja >10% i powiedzmy >20% i proszę bez teorytycznych tylko takie które występują w praktyce – gdzie owa fragmentacja jest realnym problemem.
Jeśli zapisujesz i usuwasz wiele plików z FS'a (pisząc wiele plików nie mam na myśli przerzucanie kolekcji mp3 z katalogu do katalogu od czasu do czasu).
Ale chodzi mi o konkretny scenariusz w którym zawsze występuje fragmentacja i jest ona realnym problemem.
Zrób sobie na partycji 40GB dużo plików (powiedzmy 80% wykorzystania systemu plików) wielkości np 64K, 512K, 1M, 4M, 16M, 128M i przenoś je co dwie godziny na innym system plików po czym spowrotem wrzucaj na pierwotny w innej kolejności – po miesiącu takiego ciągłego mieszania nie przekroczysz 15% fragmentacji.
"przenoś je co dwie godziny"
No i widzisz, na tym polega błąd w Twoim rozumowaniu.
Podczas przenoszenia _nie_ _dojdzie_ do fragmentacji.
Cytuję: 512K, 1M, 4M, 16M, 128M i przenoś je co dwie godziny na **innym system plików**
Może dośc niejasno się wyraziłem poprzednio bo nie ująłem jednego szczegółu że miałem na myśli losowo wybrane zestawy stworzonych plików.
"jednego szczegółu że miałem na myśli losowo wybrane zestawy stworzonych plików."
Zgadzasz się, że to zmienia postać rzeczy? :)
Nadal się nie zgadzam :-) Zapronowałem test który lepiej zasymuluje normalnie używanie systemu plików i powiedziałem że fragmentacja tam nie przekroczy 15%.
Niestety nie mam miesiąca na przeprowadzenie takiej symulacji, coś mi się jednak wydaje, że byłoby więcej niż 15%.
Jak znajdę dłuższą chwilę wolnego czasu, to przeprowadzę podobną symulację z tym, że zamiast odstępu 2h zastosuje sync, a operację przenoszenia powtórzę 372 razy.
Otóż znam pewien przykład pewnego 'normalnego' używania systemu plików, który często doprowadza do sporej fragmentacji używanej partycji.
Nastąpi to kiedy użyjemy partycji 15GB jako katalog Temp i Incoming dla klienta p2p – w moim przypadku był to mlDonkey. Kolejkowanie plików o dużych rozmiarach, których sumaryczna wielkość przekracza pojemność partycji dość szybko doprowadzi nas do stanu fragmentacji na poziomie 30% (u mnie osiągnięte maksimum wynosiło 39,8% – po jakiś 3 miesiącach na słabym łączu). Pliki ściągnięte oczywiście w krótkim czasie przenosiłem na inne partycje, ale fragmentacja pozostawała =).
Zaznaczam, że było to ładne pare lat temu i nie wiem, czy specyfika ext3 się trochę zmieniła (raczej nie).
Pierwszy raz spotkalem sie z tak rzeczowa dyskusja w komentarzach.
Przychylam sie do toku rozumowania Artura. W normalnych warunkach pracy, na serwerze plikow mojego wydzialu, gdzie czasem zapelnienie systemu plikow siegalo 80%, po kilku latach fragmentacja nie przekroczyla 15%. Uniwersyteckie podejscie zawsze moze udowodnic pewna teoretyczna mozliwosc, ktora w rzeczywistosci moze nigdy nie wystapic.
pozdrawiam
Ciekawy artykuł, który skłonił mnie do sprawdzenia, jak to jest z moim dyskiem. Ext3, 9,6 GB, zajęty w 87%, używany od roku. Wynik: 4,2% nieciągłych i-węzłów. Czyli system radzi sobie z układaniem plików na partycji całkiem-całkiem i nie ma co się martwić, że się pofragmentuje.
Fajny test pokazujący że fragmentacja na ext3 jednak istnieje – właściwie chyba nie da się stworzyć systemu plików bez fragmentacji który działał by z przyzwoitą prędkością bo albo musielibyśmy w bardzo szybkim tępie dobrnąć do końca dysku, albo po każdym usunięciu pliku przesuwać do tyłu znajdujące się przed nim bloki.
Dodać należy że ext3 pomimo fragmentacji jakoś nie zwalnia. Fragmentują się w zasadzie tylko logi które są przez większość czasu dopisywane na końcu więc nie wpływa to na szybkość działania, albo duże pliki które itak (np. filmy) są odtwarzane z użyciem programół stosujących precashing/buforowanie itd.
Teraz chyba nawet pod Vistą tak jest to ogarnięte, choć przyznam za mało na niej pracowałem by powiedzieć że to prawda. Znajomy ostatnio robił formata całkowitego i twierdzi że konieczność defragmentacji jest chyba jednak takim samym rytuałem jakim była w xpeku. MS w logu dotyczącym nowej wersji ntfsa na msdnie twierdzi niby innaczej, nie wiadomo więc komu wierzyć. Bardziej wiarygodnym źródłem analiz wydaje się być jednak kolega ;p
mi po 5 m-cach używania Visty fragmentacja partycji systemowej jest na poziomie 3% (przy wolnych 35% partycji), a nie włączałem defragmentacji. To chyba efekt uboczny jednej z głównych wad (dla wielu komentujących) czyli "mielenia dysku" (ja osobiście nie zauważyłem mielenia bez potrzeby).
A problem w komentarzach wychodzi z tego że dla jednych fragmentacja w Linuksie jest na tyle mała ze przyjmują że jej nie ma i w ten sposób powstaje mit o braku fragmentacji (spotkałem się już z takimi uproszczeniami) to oczywiście jest błędem bo niestety konstrukcja dysku twardego nie pozwala na usunięcie fragmentacji, przynajmniej nie bez znacznego spadku prędkości zapisu danych przy zachowaniu wmiare szybkiego odczytu.
Z tego co zauważyłem Vista posiada "automat" do defragmentacji a NTFS raczej jest ten sam jak w XP.
Spróbuj wyłączyć automatyczną defragmentację – podejrzewam, że fragmentacja plików zdrowo wzrośnie.
Kiedyś w XP "urwało" mi nagrywanie płyty CD na prędkości 8X – jak się okazało zbyt duża fragmentacja i bufor nie wyrobił.
Pod EXT3 z pełnym księgowaniem na 40GB nie miałem fragmentacji powyżej 1,8% (po instalacji i ustawieniu journal_data 0,8%) O_o – cały korzeń systemu był na jednej partycji a system używany był do przeglądania stron oraz pracy na Open Office.
Fragmentacja w EXT-FS jak i w ReiserFS była i będzie, zazwyczaj jest ona jednak bardzo mała, wręcz pomijalna. Nawet przy intensywnym korzystaniu z dysku poziom fragmentacji będzie bardziej niż akceptowalny, zauważcie, że niewiele osób poza wklepaniem "e2fsck -D /dev/hdxx" cokolwiek więcej z tym robi. "Fragmentacja jest czy jej nie ma?" – przypomina mi to kłótnie o wirusy na Linuksa – niby są a jednak.. ;).
Teraz używam JFS i jestem zadowolony, a zdanie "zainstaluj i zapomnij" bardzo mi tu pasuje.
Naprawdę miło jest czytać TAKĄ dyskusję.
Pozdrawiam ;)
Miales na mysli konstrukcje systemow plikow…
Ja dla ciekawości sprawdziłem. Partycja 54 gb,
1142 inodes used (0.02%)
184 non-contiguous inodes (16.1%)
liczba i-węzłów z blokami ind/dind/tind: 1066/1041/0
3065514 blocks used (23.03%)
0 bad blocks
1 large file
System chyba normalnie użytkowany, partycja przeznaczona na muzykę (mp3).
Natomiast na partycji /home – wielkość 150 gb, po 2-3 latach, przy trzech użytkownikach i zajętości 57% fragmentacja jest na poziomie 13,3%. Szczerze mówiąc, myślałem, że będzie gorzej (zwłaszcza na /home). Czyli nie ma się co chyba rzeczywiście przejmować, ale z drugiej strony, nie wiadomo, co będzie za następne 3-5 lat. Może program do defragmentacji się przyda? ;-)
NIEUMIEJETNE UŻYCIE ITD – CO TA SZAJS? MAM KLIKNĄĆ I ZA CHWILĘ WSZYSTKO MA HULAC! CO ZA BZDETY!
Ehm… gdybym nie napisał ostrzeżenia i ktoś straciłby dane (jak by nie było z własnej winy), to jak znam życie oskarżałby o to mnie. A tak zawsze mogę powiedzieć, że ostrzegałem i kazałem czytać dokumentację fsck.
czytajac komentarze to ja chyba jestem jakis zboczony skoro sciagam torrentem pliki, bo moja partycja ma:
1428 inodes used (0.04%)
887 non-contiguous inodes (62.1%)
liczba i-węzłów z blokami ind/dind/tind: 972/673/1
6851881 blocks used (86.34%)
0 bad blocks
2 large files
oO
Wygląda na to, że niektóre programy P2P potrafią bardzo namieszać na partycji.
W ilu przebiegach możesz ją zdefragmentować za pomocą ok_defrag?
Potrafią namieszać dlatego bo prawdopodobnie używają sparse-files i po utworzeniu kilku sparse-filesów o wielkości np. kilku GB i zapisywaniu równolegle do kilku dane robią się wymieszane stąd taka fragmentacja.
Aha zapomniałem – przeniesienie/skopiowanie pliku sparse powoduje rozrośnięcie się do pełnej wielkości także żeby nie było później zdziwienia że zniknęło trochę miejsca ;-)
AFAIR taki Azureus standardowo tworzy plik minimalnej wielkości i ciągle go powiększa. Jeśli ściągasz więcej niż jeden plik (a często pojedynczy torrent ma ich kilka do kilkuset), to fragmentacja robi się kosmiczna.
Poszukaj opcji w rodzaju "Allocate and zero new files on creation" (ofc w innym kliencie nie musi nazywać się tak samo).
Dzieki, zaptaszylem opcje w swoim Azareusie.
U mnie chciałem sobie /home zdefragmentować i:
Traceback (most recent call last):
File "./ok_defrag", line 176, in
main()
File "./ok_defrag", line 173, in main
list_of_d = list_of_dirs(options.directory)
File "./ok_defrag", line 48, in list_of_dirs
d = d.split(" ")[1]
IndexError: list index out of range
Uruchomiłeś jako zwykły użytkownik a w /home masz katalog którego zawartości nie możesz odczytać (lost+found?). Przynajmniej mam coś takiego u siebie
list_of_dirs_tmp = find: /mnt/loop0/lost+found: Brak dostępu
du: nie można przeczytać katalogu `/mnt/loop0/lost+found': Brak dostępu
du: nie można przeczytać katalogu `/mnt/loop0/lost+found': Brak dostępu
No i ten sam traceback. Program na razie jest jeszcze w wieku dziecięcym, ale raczej nigdy nie będzie dobrze działał na uprawnieniach zwykłego u żytkownika.
U mnie, po 7 miesiącach używania Ubuntu na ext3, na partycji ok 60gb, zapełnionej zazwyczaj ~80-90% fsck daje następujący wynik:
10540 non-contiguous inodes (4.7%)
Nie wiem co autor chciał udowodnić tym eksperymentem. Owszem fragmentacja na unixowych systemach plików występuje, jednak przy normalnym użytkowaniu jest to zjawisko, którym nie ma sensu się przejmować.
Ja na przykład mógłbym próbować udowodnić że 100% ludzi na ziemi to niscy siwiejący panowie po pięćdziesiątce. Jako grupę testową przyjąłbym braci Kaczyńskich.
Ehm.. napisałem, że nie opłaca się defragmentować jeśli masz poniżej 10%. Jeśli masz 4%, to się ciesz. Są tacy co mają 20+, to właśnie do takich przypadków powstał ten program.
"Owszem fragmentacja na unixowych systemach plików występuje, jednak przy normalnym użytkowaniu jest to zjawisko, którym nie ma sensu się przejmować."
Nie wiem dlaczego ludzie zakładają, że jeśli u nich coś wygląda tak a nie inaczej, to u wszystkich innych bez wyjątku też tak będzie. Tu chyba znowu odzywa się syndrom koloru garażu na rower … bikeshed dot com
Dyskusja zeszła na mało ważny temat występowania fragmentacji – to mnie naprawdę nie interesuje, bo wiem, że ona istnieje, występuje etc. Wolałbym otrzymać jakieś sugestie jak ulepszyć program a nie 20 komentarzy nie na temat.
Mnie naprawdę nie interesuje dyskusja o kolorze roweru (zanim skomentujesz to zdanie, zapoznaj się z zawartością bikeshed dot com)
albo na odwrót: po 8 latach używania nie straciłem nigdy danych bo zawsze pamiętałem o kopiach zapasowych i regularnym skanowaniu dysków, więc firmy oferujące odzyskiwanie danych nie mają prawa istnienia.
@optimizationkit, wykonuję to z roota… :/
Rozumiem że robisz to na jakiejś testowej partycji i nie masz tam ważnych danych? :-) Ja bym się bał uruchamiać coś napisanego na kolanie co grzebie w moich plikach. Poza tym co to za programowanie przez 'commands' i wywoływanie systemowych poleceń.
(Pisanie i udostępnianie programów powoli traci sens…)
Mógłbyś powiedzieć co jest takiego złego w commands, czy tylko tak pier$%@, żeby coś napisać?
To że programu nie pisze się przez wywołania systemowych poleceń a przez mechanizmy które udostępnia język, bo:
1. Format zwracanych danych może różnić się między wersjami tych poleceń i może to prowadzić do nieokreślonych skutków.
2. Nie mamy kontroli nad błędami (których w ogóle nie sprawdzasz).
Poza tym czym różni się ok_defrag od defrag CK? Oprócz tego że jest w Pythonie w którym wołasz te same polecenia nie sprawdzając nawet statusu zakończenia (co w oryginalnym skrypcie jest).
"1. Format zwracanych danych może różnić się między wersjami tych poleceń i może to prowadzić do nieokreślonych skutków."
IMO chybiony argument. Taki sam problem może występować w setkach tysięcy skryptów shellowych – jakoś to ludziom nie doskwiera.
"2. Nie mamy kontroli nad błędami (których w ogóle nie sprawdzasz)."
Sprawdzanie błędów które są ważne np. błędy i/o jest na poziomie sum kontrolnych – według mnie jest to skuteczniejsza metoda niż poleganie na pythonowym except.
"Poza tym czym różni się ok_defrag od defrag CK"
Widzę, że przejrzałeś tylko kod – sposobem układania danych oraz zastosowaniem sum kontrolnych do sprawdzania poprawności plików (dzięki temu zawsze zostaje poprawna kopia pliku).
Ale zdarza się, więc po co w ogóle użyłeś Pythona skoro używasz go do interpretowania poleceń systemowych? A setki tysięcy skryptów nie mieszają na taką skalę w plikach.
Ale miałem na myśli błędy poleceń, już lepsze było by użycie getstatusoutput() który zwraca status. Ale jak już jesteśmy przy błędach I/O no to trzeba było użyć C a nie Pythona i byłbyś maksymalnie blisko systemu.
Sprawa się skomplikowała ;)
Wrzuć do 46 linijki
print "list_of_dirs_tmp = %s" % list_of_dirs_tmp
i wyślij mi na maila rezultat.
zadziałało bez tego, jak przejechałem partycje fsck.ext3
/dev/sda3: 577035/2101152 plików (7.1% nieciągłych), 3879346/4199572 bloków
Nie spodziewałem się tak pozytywnego wyniku po systemie, który ma prawie 2 lata i jest ostro katowany czy to dużymi, czy małymi pliczkami.
Natomiast problem fragmentacji faktycznie kiedyś się może pojawić. Pytanie natomiast, czy nie jest najprościej pozbyć się jej, robiąc po prostu "tar -czpvf archiwum.tar.gz /", "rm -rf /", a potem rozpakowanie tego systemu ponownie… (oczywiście, pakując na inną partycję i z live'a ją przywrócić)…
"Pytanie natomiast, czy nie jest najprościej pozbyć się jej"
To rozwiązanie oczywiście też jest dobre i daje lepsze rezultaty, jednak nie zawsze jest możliwe np. jak masz dużą ilość danych.
Dla Ext4 powstaje profesjonalny program do defragmentacji, więc problem zostanie w miarę szybko rozwiązany.
ok, life test:
<code>
df -h | grep sda2
/dev/sda2 19G 4.5G 14G 26% /
</code>
<code>
sudo fsck.ext3 -nfv /dev/sda2 :
213818 inodes used (17.47%)
1369 non-contiguous inodes (0.6%)
# of inodes with ind/dind/tind blocks: 9534/98/0
1210104 blocks used (24.77%)
</code>
<code>
df -h | grep sda5
/dev/sda5 58G 45G 14G 77% /hda5
</code>
<code>
sudo fsck.ext3 -nfv /dev/sda5 :
10623 inodes used (0.14%)
83 non-contiguous inodes (0.8%)
# of inodes with ind/dind/tind blocks: 1762/141/1
11867868 blocks used (77.08%)
</code>
<code>
df -h | grep home
/dev/mapper/home 111G 97G 8.0G 93% /home
</code>
<code>
sudo fsck.ext3 -nfv /dev/mapper/home
144897 inodes used (0.99%)
5643 non-contiguous inodes (3.9%)
# of inodes with ind/dind/tind blocks: 18057/3893/1
25748584 blocks used (87.88%)
</code>
wiec jak z ta fragmentacja ? jak widac w rzeczywistosci jest NIEWIELKA (c.b.d.u)
Partycja z drzewem portage gentoo, na której co kilka dni tworzone i usuwane są setki plików ma u mnie fragmentacje 4.6%.
System to ReiserFS, rozmiar 1GB, zapełnienie 25%, wiek 2-3 lata.
Jeżeli komuś bardzo zależy na defragmentacji, to polecam Shake — http://vleu.net/shake/
z ciekawości zrobiłem eksperyment. partycja systemowa, używana dość normalnie – aktualizacje, instalacja/deinstalacja programów – defragmentacja 1,7%. Home – defragmentacja 3,5%.
Partycje zajęte są od roku, system używany w domu dość intensywnie.
Chciałem zdefragmentować sobie partycje poniewaz nieciagłość na niej wynosi około 35%. ok_defrag zwrocił takie cos:
from: can't read /var/mail/optparse
ok_defrag: 7: Syntax error: "(" unexpected
Prosze o pomoc
Pracuje w duzej korporacji, gdzie zajmuje sie bezpieczenstwem. Logi ktore zbieram generuja duzy ruch na partycjach. Przepostowosc danych na poziomie 20GB dziennie. Nastepnie sa one dzielone i grupowane tematycznie, archiwizowane i rotowane. W dodatku, czesto sa przegladane pod katem roznych zdarzen. Zajmuja sie tym cale klastry komputerow, z ktorych kazdy ma 2TB przestrzeni dyskowej do swojej dyspozycji. Poziom zapelnienia utrzymywany jest na 60-80%.
Poziom fragmentacji wynosi 4,2%. System plikow ext3. Partycje te sa w uzyciu przynajmniej od 5 lat.
Tylko raz spotkalem sie z serwerem LMS, postawionym na sprzecie IBM gdzie poziom fragmentacji wynosil 72%. Powodem bylo podlaczenie przez administratora dodatkowego dysku na backup-y, ktory automatycznie przy starcie systemu zostal hardware-owo ustawiony na RAID z mirroringiem, co doprowadzilo w konsekwencji do problemow przy synchronizacji dyskow. Jak wiadomo lepiej na linuksie robic takie rzeczy programowo… a jak ktos nie wierzy to niech sie sam przekona- chociaz moze to byc bolesne doswiadczenie ;)
Partycja ext3 20 GB, 99% zajęte. Ostatnio sporo ściągałem i oczywiście tworzyłem miejsce na nowe pliki. Wprost idealna pożywka dla fragmentacji. A tu zonk: tylko 9712 non-contiguous files (2.5%). Czyż są piękniejsze rzeczy na tym świecie?