Dlaczego defragmentacja dysku pod Linuksem nie jest potrzebna
Opublikowany 20 listopad, 2007 w Linux, Techblog Tagi: hardware, LinuxJest to pytanie, które bardzo często pojawia się na różnego typu forach i w różnych dyskusjach kiedy nowi użytkownicy Pingwina nie są w stanie znaleźć narzędzia do defragmentacji dysku dla nowo zainstalowanego systemu, które przecież tak często używali pod Windowsem. Mam nadzieję, że poniższy opis odpowie Wam na pytanie, dlaczego niektóre systemy są mniej podatne na defragmentacje niż inne i dlaczego mniej cierpią z tego powodu.
Od razu mówię, że ludzie szukający tu stricto technicznych odpowiedzi zawiodą się. Zamiast wdawać się w czysto techniczne dyskusje postaram się zobrazować to w ASCII… dla niektórych pewnie będzie to warte więcej niż tysiąc słów.
Zaczynajmy więc.
Tutaj jest grafika która posłuży mi do wyjaśnienia problemu.
a b c d e f g h i j k l m n o p q r s t u v w x y z a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 g 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 h 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 l 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 n 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Jest to odwzorowanie (bardzo małego) dysku twardego. Jako że dysk jest kompletnie pusty stąd mamy same zera. Litery a-z na samej górze i te po lewej stronie posłużą nam do odwzorowania każdego bajta danych. W lewym górnym rogu mamy “aa”, w górnym prawym “za”, w dolnym rogu jest “az”. Mam nadzieję, że łapiecie o co chodzi.
Zaczniemy od prostego systemu plików z grona tych, który jest dobrze znany większości użytkowników. Będzie on potrzebował od czasu do czasu defragmentacji danych.
Zajmiemy się systemem plików który w nazwie zawiera FAT. Prawie każdy z nas go używa… i nieważne czy używasz Linuksa czy Windowsa… na pewno miałeś z nim jakąś styczność… chociażby używając pamięci Flash pod USB.
Niestety FAT bardzo cierpi z powodu fragmentacji danych.
Dodamy plik do naszego dysku i nasz system plików będzie wyglądał następująco:
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t a e l e 0 0 0 0 0 0 0 0 0 0 b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C e H e l l o , _ w o r l d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
(Wiersze g-z zostały pominięte dla większej przejrzystości)
Spróbujmy wytłumaczyć to co widzicie… Pierwsze cztery rzędy na dysku są zajęte przez tzw. “Table of contents”, albo TOC. To TOC przechowuje informacje o każdym pliku na naszym dysku. W powyższym przykładzie TOC zawiera jeden plik o nazwie “hello.txt” i informuje nas, że zawartość tego pliku może być odnaleziona pomiędzy “ae” i “le”. Przechodzimy do tej lokacji i widzimy, że zawartość tego pliku to “Hello, world”.
Do tej pory logiczne? Dodajmy kolejny plik:
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t a e l e b y e . t x t m e z b e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C e H e l l o , _ w o r l d G o o d b y e , _ w o r l d f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Jak widzicie, kolejny plik został dodany bezpośrednio za pierwszym. Idea tego jest taka, że jeżeli pliki są trzymane razem, to dostęp do nich będzie szybszy i łatwiejszy. Jak większość z Was pewnie wie, najwolniejszą częścią dysku twardego jest głowica… im mniejszą drogę ma do przebycia tym szybciej będziemy mogli zapisać/odczytać dane.
Problem pojawia się wtedy, kiedy zachce nam się edytować pierwszy plik. Powiedzmy, że chcemy dodać do naszego słowa “Hello” wykrzykniki..
I mamy problem… przecież nie ma na to miejsca… plik “bye.txt” stoi nam na drodze to pełni szczęścia. Teraz mamy dwie opcje, z których żadna nie jest idealna:
- Usuniemy plik z jego oryginalnego miejsca na dysku i dodamy nowy, większy plik po drugim (bye.txt) - towarzyszy temu wiele procedur zapisu/odczytu danych.
- Podzielimy plik tak żeby istniał w dwóch miejscach, ale żeby nie było żadnych wolnych przestrzeni. Sprawa szybka do wykonania, ale znacząco spowolni dostęp do pliku z oczywistych powodów.
Spróbujmy to zilustrować… Problem nr 1.
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t a f n f b y e . t x t m e z b e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C e 0 0 0 0 0 0 0 0 0 0 0 0 G o o d b y e , _ w o r l d f H e l l o , _ w o r l d ! ! 0 0 0 0 0 0 0 0 0 0 0 0
Problem nr 2:
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t a e l e a f b f b y e . t x b t m e z e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C e H e l l o , _ w o r l d G o o d b y e , _ w o r l d f ! ! 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Problem nr 2 pokazuje nam, dlaczego takie systemy plików potrzebują częstej defragmentacji. Pliki są umieszczone bezpośrednio po sobie, a co za tym idzie za każdym razem kiedy będziemy powiększać plik, będzie on coraz bardziej fragmentowany (dzielony). Kiedy natomiast rozmiar pliku się zmiejszy to powstanie pusta luka.
Nie trzeba geniusza żeby się domyślić, ze po krótkim czasie nasz dysk będzie zaśmiecony podzielonymi plikami i lukami… oczywiście idzie za tym spory spadek wydajności dysku. Może się zdarzyć na przykład, że część pliku znajduje się na początku dysku, część w środku, a część na końcu obszaru danych.
Spróbujmy teraz zobaczyć, co się stanie jeżeli przyjmiemy inną strategię. Pierwszy system plików jest idealny, kiedy mamy tylko jednego użytkownika, który będzie używał plików mniej więcej w kolejności ich utworzenia i nie będzie ich za często modyfikował… dość nierealne prawda?
Linux jednak w swym założeniu został stworzony jako system dla wielu użytkowników. Przyjęto, że będzie będzie kilku użytkowników, którzy będą próbować modyfikować ten sam plik w tym samym czasie… a do tego potrzebna już jest kompletnie inna strategia przechowywania danych.
Kiedy na Linuksowym systemie plików stworzymy plik o nazwie “hello.txt” będzie on wyglądał tak:
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t h n s n 0 0 0 0 0 0 0 0 0 0 b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 g 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 h 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 l 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 n 0 0 0 0 0 0 0 H e l l o , _ w o r l d 0 0 0 0 0 0 0 o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Gdy zostanie dodany kolejny plik:
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t h n s n b y e . t x t d u q b u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 g 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 h 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 l 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 n 0 0 0 0 0 0 0 H e l l o , _ w o r l d 0 0 0 0 0 0 0 o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 u 0 0 0 G o o d b y e , _ w o r l d 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Przewaga takiego rozwiązania polega na tym, ze głowica dysku znajduje się pośrodku dysku i większość plików będzie blisko siebie.
Plus jeżeli spróbujemy dodać wykrzykniki do naszego pliku, zobaczcie ile sprawi nam to kłopotu:
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t h n u n b y e . t x t d u q b u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 g 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 h 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 l 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 n 0 0 0 0 0 0 0 H e l l o , _ w o r l d ! ! 0 0 0 0 0 o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 u 0 0 0 G o o d b y e , _ w o r l d 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Dokładnie… wcale.
Pierwszy system plików próbuje wstawiać wszystkie pliki najbliżej początku jak to tylko możliwe, a to sprawia, że po jakimś czasie pliki ulegną fragmentacji i nie zostanie nic wolnego miejsca.
Drugi natomiast rozrzuca pliki po dysku żeby było miejsce na ich ewentualną edycję. Może też rozmieszczać pliki “w locie” gdyż jest na to dużo miejsca.
Defragmentacja pierwszego typu systemu plików jest procesem bardzo pracochłonnym i niezbyt praktycznym podczas normalnego użytkowania.
Defragmentacja drugiego typu systemu plików staje się problemem tylko wtedy, gdy nie ma już wolnych przestrzenie gdzie większe pliki mogłby się zmieścić bez fragmentacji. Do czasu aż będziecie używać więcej niż 80% powierzchni dysku raczej to wam nie grozi.
Warto też wiedzieć, że nawet jeśli system twierdzi, że dysk jest kompletnie zdefragmentowany to biorąc pod uwagę geometrię dysku fragmentacja może cały czas być obecna… przeciętny dysk ma kilka talerzy…
Powiedzmy teraz, że nasz przykładowy dysk ma dwa talerze, gdzie pierwszy zajmuje przestrzeń aa do zm, natomiast drugi od an do zz:
a b c d e f g h i j k l m n o p q r s t u v w x y z a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 g 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 h 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 l 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 a b c d e f g h i j k l m n o p q r s t u v w x y z n 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Poniższy plik nie będzie uważany jako fragmentowany gdyż zachowana jest ciągłość od rzędu m do n. Nie zmienia to jednak faktu, że głowica będzie musiała lecieć od samego końca pierwszego talerza do początku drugiego żeby odczytać ten plik.
a b c d e f g h i j k l m n o p q r s t u v w x y z a T O C h e l l o . t x t r m e n 0 0 0 0 0 0 0 0 0 0 b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 g 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 h 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 l 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 H e l l o , _ w o a b c d e f g h i j k l m n o p q r s t u v w x y z n r l d ! ! 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Mam nadzieję, że powyższy opis chociaż trochę pomógł Wam zrozumieć budowę systemu plików, jak bardzo dysk może cierpieć z powodu fragmentacji danych oraz dlaczego pod Linuksem nie ma narzędzi do defragmentacji dysków. Jeżeli nie, to jestem otwarty na sugestie. Piszcie.
Oryginalny artykuł
42 Komentarzy dla “Dlaczego defragmentacja dysku pod Linuksem nie jest potrzebna”
- 1 Pingback on 21 listopada, 2007 at 19:11
- 2 Pingback on 15 września, 2009 at 16:57
Odpowiedz
Najświeższe komentarze
 |
Tagi:Archiwa |
|||
Ciekawe przedstawienie problemu jak na ten poziom zagłębienia się w całą sprawę struktury dysku, fragmentacji. Mógłbyś jedynie pokolorować swoje piękne “grafiki” aby było czytelniej
Spoko artykul. Dzieki!
Do wizualizacji fragmentacji dysku pod Linuksem można użyć davtools (Disk Allocation Viewer): http://davtools.sourceforge.net/
“towaRZyszy temu wiele procedur”
No w sumie racja, jezeli chodzi o FAT i FAT32, ale juz np NTFS jakos lepiej sobie radzi z fragmentacja, nie jest juz taki pocięty, co prawda dalej jest problem ale juz mniejszy, standardowe zabawki z Windows, srednio sobier radza z fragmentowanem danych, ale jest tez troszke innego softu co lepiej sie sprawuje. Szkoda ze opisales system Ext2/3 a nie napisales nic i “księgowanych” systeemach pod linux, te dla odmiany maja jeszcze szybszy dostep do danych gdyż wykorzystuja dla przykladu polowe taleza na TOC ( indeksy plikow ), a reszta na dane, i teraz glowica wie gdzie znajdzie “cały” plik, lub jezeli juz nawet fragmenty to i tak to idzie o niebo szybciej, bo zna z gory adresy dysku, a nie szuka tych plikow po calym talezu jak to jest w przypadku Windows.
To, ze “dlaczego pod Linuksem nie ma narzędzi do defragmentacji dysków” to nie jest do konca prawda. Od dawna byl e2defrag. Wprawdzie nikt go nie uzywa, nie dziala najlepiej z ext3 i chyba od dawna jest nierozwijany, ale jest
To, ze ?dlaczego pod Linuksem nie ma narzędzi do defragmentacji dysków? to nie jest do konca prawda. Od dawna byl e2defrag. Wprawdzie nikt go nie uzywa, nie dziala najlepiej z ext3 i chyba od dawna jest nierozwijany, ale jest
“Defragmentacja drugiego typu systemu (…) do czasu aż będziecie używać więcej niż 80% powierzchni dysku raczej wam nie grozi.”
No dobrze. A co się dzieje, gdy jednak danych na dysku mam dużo i chcę wpakować plik tam plik większy niż największa wolna przestrzeń? Czy plik jest dzielony? Czy włącza się jakieś automatyczne przesuwanie małych plików, by móc zmieścić ten nowy duży? Co się dzieje, gdy dużo pracuję na dysku z małą ilością miejsca?
“Nie zmienia to jednak faktu, że głowica będzie musiała lecieć od samego końca pierwszego talerza do początku drugiego żeby odczytać ten plik.”
Moje uwagi:
2. Nie sądzisz, że projektanci softu do dysków to nie są amatorzy i tak ustawili numerację sektorów na dwóch kolejnych talerzach, żeby żadnego skoku głowicy nie było? (albo czytają dane z dwóch talerzy z przeplotem, żeby zwiększyć transfer?)
1. Z tego zdania wynika, że dysk ma jedną głowicę na kilka talerzy
“Wiersze g-z zostały pominięte dla większej przejRZystości”
Poza tym fajny wpis.
ja kilka razy bez problemu uzylem e2defrag na ext3 - w celach testowych, nie powiem, nawet dziala
Dobry artykuł, godny polecenia hardware’owym laikom:)
?Nie zmienia to jednak faktu, że głowica będzie musiała lecieć od samego końca pierwszego talerza do początku drugiego żeby odczytać ten plik.? - chyba NIE będzie musiała - po to wymyślono cylindry, aby przy większej liczbie talerzy zapis następował cylinder po cylindrze (cylinder jak sama nazwa wskazuje - zbiór ścieżek o tej samej średnicy - walec), a nie systemem - “jak się strona zapełni, to idziemy na drugi talerz” (ang. head - strona talerza, nie mylić z polską “głowicą” w znaczeniu “badziewie do przetwarzania zmian pola EM na prąd”). Dzięki temu ruchy głowic są zminimalizowane do niezbędnego poziomu i systemowi lub systemowi plików NIC do tego - dba o to “elektronika” dysku. Jeśli ktoś nie wierzy - niech sprawdzi (np. wchodząc do “biosu”) ile talerzy ma jego dysk, liczba talerzy=liczba heads/2. Potem wystarczy się zastanowić, czy te np. 32 talerze zmieszczą się w naszym dysku … i dlaczego są 32 talerze, choć w rzeczywistości jest jeden… (sprawdzenie tego jest już niestety “niszcące” dla dysku
Sprzęt często “oszukuje” użytkownika, system lub inny sprzęt, aby rozmawiać standatdowym językiem i w rzeczywistości sprawy są bardziej skomplikowane, niż w teorii. Poza tym artykuł jest jak najbardziej OK!
Artykuł fajny i w prosty sposób tłumaczy podstawowe zasady działania systemu plików. Ale z tezą nie do końca się zgadzam - systemy typu ext (2,3 i obecnie 4) to po prostu inna zasada działania; fragmentacja plików jest tyle że nieco mniejsza. Dobrym “defragiem są programy typu Shake http://vleu.net/shake/ . Najbardziej zaawansowaną koncepcją defragmentacji była (nieststy dotąd nie działająca) defragmentacja kompresja podczas działania systemu (wolne zasoby / niski priorytet) w reiser4 (repacker plug-in).
A ja myślałem, że cały artykuł, to wstęp do reszty ; ]
IMHO artykuł trochę nieadekwatny do rzeczywistości. Defragmentacja dla ext3 _jest_ potrzebna. Trwają pracę aby udostępnić mechanizmy defragmentacji online dla ext4. Odsyłam do artykułu:
http://www.linuxinsight.com/files/ols2007/sato-reprint.pdf
W najbliższym czasie postaram się poprawić artykuł o poprawki zawarte w komentarzach. Dzięki!
Swietny artykul, prosto i przejrzyscie. Wyrazy uznania.
W przypadku posiadania wielu talerzy, bloki nie są ułożone tak jak Ty to pokazałeś. Zamiast tego, np mając dwa talerze, bloki parzyste znajdą się na jednym a nieparzyste na drugim. Taki wniosek przynajmniej wynika z testów prędkości względem numeru bloku. Wysokie numery są wewnątrz dysku a niskie na zewnątrz, nie ma skoków które występowałyby gdyby bloki były numerowana tak jak przedstawiłeś.
Przydało by się abyś podał źródło z którego korzystałeś, jak mniemam jest to ten artykuł sprzed roku: http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting
@Piotr Gasidlo
Taj jak napisałem, jeżeli nie zapełnisz dysku powyżej 80%, to fragmentacja praktycznie nie zajdzie. Oczywiście nie ma siły, żeby nie było podzielonych plików jeżeli chcemy zapchać dysk do ostatniego bajta danych.
A pytanie z innej beczki. Jak zrobimy fsck, to wyskakuje że x% plików jest nieciągłych (not continous). Czy to określa naszą fragmentację? I co jest zalecane, kiedy ten procent jest poważny?
Ponoć MacOS X robi defragmentację w tle, jak dysk chwilowo nie ma nic do roboty.
Super art! Pozdrawiam!
“Przyjęto, że będzie będzie kilku użytkowników, którzy będą próbować modyfikować ten sam plik w tym samym czasie? a do tego potrzebna już jest kompletnie inna strategia przechowywania danych.”
Jak kilku użytkowników zacznie modyfikować ten sam plik w tym samym czasie to ogólnie jest pozamiatane i fragmentacja w takim przypadku to najmniejsze zmartwienie.
pozdr,
fEnIo
@rw “e2defrag na ext3 ” Lepiej tego nie rób… w łatwy sposób możesz sobie uszkodzić pliki gdyż e2defrag nie obsługuje sporej liczby funkcji ext3
@nbvcxz. Już lepiej używać pyfragtools… jest to narzędzie o wiele bezpieczniejsze od “Shake”
@sunrise_son Owszem. Określa to fragmentację plików, jednak systemy linuksowe bardzo dobrze radzą sobie nawet z dużą wartością fragmentacji bez utraty wydajności. Jeżeli koniecznie chcesz uspokoić sumienie to użyj pyfragtools
@Bartosz Feński. Mój błąd. Chodziło o to, że jeden plik może być wielokrotnie modyfikowany przez różnych użytkowników.
@skiter
Zarówno ext3 jaki i NTFS są systemami z journalingiem.
Witam!
A ja mam pytanie jak linux radzi sobie z fat32? czy korzystając z linuksa i np. fat32 na dysku przenośnym nie musimy obawiać się fragmentacji? Czy brak fragmentacji to kwestia sprytu systemu plików czy systemu operacyjnego?
@mlodedrwale. Systemu plików. Linux radzi sobie z fatem tak samo jak Windows… i tu i tu będzie występować fragmentacja.
XFS ma narzędzie do defragmentowania dysku, zwie się xfs_fsr (z pakietu xfsdump), więc po coś ta defragmentacja jest potrzebna
Nie znam się na tym za bardzo, ale wydaje mi się, że możliwe jest napisanie sterownika dla systemu plików FAT (i myślę, że taki już jest), który zapisywałby pliki nie jeden za drugim, lecz “rozrzucał” je po całym dysku.
99,9% informacji w manualach jest…, pozostałe 0,1% to zdrowy rozsądek…
Fragmentacja jest na każdym systemie plików jest, jeśli nawet w stopniu niezauważalnym przez użytkownika… ale jest.
Czemu link do zrodla jest z artybutem rel=”nofollow”?
iso9660 nie ma defragmentacji
@Name (wymagane). A wiesz o czym piszesz? wiesz dokładnie czym jest rel=nofollow? To niczego nie blokuje i nie zapobiega indeksowaniu przez wyszukiwarki. Jeżeli zrozumiesz czym jest ten parametr to zrozumiesz też dlaczego tam jest.
Nikt nie napisal, ze w systemach wielodostepowych fragmentacja jest kozystna…
z tego co tu wyczytałem, najlepiej kupić sobie dysk 750GB zawsze mieć ze 100GB w zapasie i możemy sobie spokojnie na linuxie pracować bez cudowania z defragmentacją
dzięki za wytłumaczenie; teraz wszystko kapuję
Jeśli chodzi o partycje z systemem xfs to przedewszystkim opłacalna jest defragmentacja partycji gdzie składowane są duże pliki (np.: multimedia). Scalanie czesci plików na partycjach przyspiesza ich odczyt, co daje nam mniej obciążony dysk. Używam tego systemu plików od 3-4 lat na desktopie razem z defragmentacją i gorąco polecam
.
A co z plikami ext4 ?! Będą wymagać defragmentacji?!
Czy w ogóle ta fragmentacja spowalnia sys?