2. NTFS 5.1 vs FAT32 part 1

UWAGA! Partycje NTFS, nie mogą być zapisywana przez Windows 98/Me bez użycia dodatkowego oprogramowania (płatnego). Darmowe programy pozwalają tylko na odczyt takiej partycji np. Paragon NTFS for Windows 98 demo.

Używanie FAT32, który tylko pozornie może konkurować z NTFS jest w większości wypadków pozbawione sensu w przypadku systemów z jądrem NT - Windows NT 4.0, XP, 2000, 2003.

Nie trzeba formatować dysku, aby zmienić FAT32 na NTFS... Menu Start - Uruchom - wpisz 'convert X: /fs:ntfs' (X = partycja do konwersji). Po takim zabiegu należy bezwarunkowo użyć programu, który defragmentuje: MFT, MFT Zone i Metadata.

Na początek słów kilka

Pojawienie się nowe systemu plików NTFS [New Technology File System] w Windows 2000 a następnie w Windows XP zrobiło sporo zamiaszania. Podniosły się głosy mówiące o słabej wydajności NTFS w porównaniu z FAT32. Winę za to ponoszą większe wymagania NTFS względem sprzętu, polecenie convert c: /fs:ntfs, programy firm trzecich i... niewiedza użytkowników. Czy aby taka jest prawda? Czy NTFS jest mniej wydajny od FAT32? Zweryfikujmy tę opinię. Na początku trzeba wyjaśnić kilka pojęć:

NTFS 5.1 - jest to kolejna generacja systemu NTFS, której używają Windows XP i XP Pro. Windows 2000 używał NTFS 5.0.

FAT32 - System plików używany od czasów Windows 95. Wywodzi się od FAT12, który jest używany do dziś do... formatowania dyskietek.

FAT32x - od FAT32 extended.
Jest to rozszerzenie FAT32, które pozwala na obsługę parytycji z więcej niż 1024 cylindrami, i większych niż 8,4 GB. Nieco różni się od FAT32, lecz programy, które operują na partycjach FAT32, od dawna radzą sobie doskonale z FAT32x. Jest wolniejszy od FAT32 ze względu na swoja konstrukcję!!!

I jeszcze małe przypomnienie jednostek zapisu informacji na dysku.

• 1bit = jest to cyfra zapisana na dysku, dokładniej 0 lub 1
  
• 1 B [bajt] = 8 bitów ułożonych kolejno po sobie
  
• 1 KB [kilobajt] = 1024 B - ponieważ komputer PC operuje na liczbach w systemie binarnym [wielokrotniści cyfry 2] i nie orientuje się w systemie dziesiętnym, nie 1000 a 1024 B [2¹⁰] składają sie na jeden KB
  
• 1 MB [megabajt] = 1024 KB
  
• 1 GB [gigabajt] = 1024 MB
  
• 1 TB [terabajt] = 1024 GB
  

Zanim przejdziemy do konkretów, chciałbym zauważyć, że istnieje zasadnicza różnica pomiędzy partycją a dyskiem. Wydaje się to oczywiste, ale często można spotkać błędy merytoryczne polegające na odnoszeniu systemów plików do dysków. System plików należy odnosić zawsze do partycji, a wydajność samego dysku to zupełnie inna kwestia, którą trzeba omawiać z osobna.

FAT32/32x

FAT32 jest mało skomplikowanym systemem plików, jego ograniczenia wynikają z bardzo starej architektury.

FAT32

FAT32x

Schemat należy czytać dosłownie. Na dysku fizycznie najpierw znajduje się w praktyce bardzo mały boot sektor [0.5 KB], następnie tablica FAT i jej kopia, główny katalog, a na końcu ciąg danych. FAT32x ma swoje tablice na końcu partrycji.

Jak widać na rysunku partycję FAT32 można podzielić na 5 części:

• Boot Sector - zawiera dane o atrybutach partycji i ewentualnie pliki inicjujące start systemu operacyjnego.
  
• FAT [File Allocation Table] - jest to tablica alokacji plików. To właśnie od niej powstała nazwa systemu plików. Liczba w nazwie, to po prostu liczba bitów określająca właściwości jednego klastra. 32 bity = 4 B na klaster w tablicy FAT32.
  
• Kopia FAT - kopia tablicy alokacji stanowiąca pewną formę zabezpieczenie przed uszkodzeniem podstawowej tablicy alokacji. Niestety jest to bardzo prymitywne zabezpieczenie i bardzo często zawodzi.
  
• Główny katalog - pozostałość po pierwotnych strukturach FAT12 i FAT16. Jest on nieco inaczej traktowany niż pozostałe dane. W systemie FAT32 stanowi jest on pierwszą częścią obszaru danych.
  
• Obszar danych - tu zapisywane są pliki.
  

  W obszarze danych znajdują się katalogi, każdy plik ma swój 32 B rekord w określonym katalogu. Ponieważ najmniejszy klaster ma 512 B, recordy w FAT32 nigdy nie ulegają fragmentacji. W zależności od wielkości klastra katalog może pomieścić od 16 do 2048 recordów. Dla klastra 4 KB jest to 128 rekordów dla plików i folderów. Dla większości folderów jest to liczba wystarczająca, aby katalog mieścił się w jednym klastrze, jednak często spotykana opinia mówiąca, że katalogi FAT32 nie ulegają fragmentacji - to kłamstwo!!!
  

NTFS 5.1

NTFS to system plików nowej generacji stworzony z myślą o sprawnym zarządzeniu dużymi partycjami i bezpieczeństwie zgromadzonych danych. O jego żywotności dobrze świadczy fakt, że Microsoft zdecydował się pozostać przy NTFS podczas prac nad następcą XP - systemem Vista [nazwa kodowa Longhorn].

NTFS podobnie jak FAT ulegał, a w zasadzie nadal ulega modernizacji. Do tej pory miało miejsce pięć odsłon tego systemu plików, który zyskuje swoje "cyferki" od systemów dla których zostały skonstruowane. Oczywiście poszczególne wersje NTFS różnią się od siebie! NTFS 5.0 znany z Windows 2000 jest mniej zaawansowany technicznie niż 5.1 z XP.

System	Wersja NTFS
NT 3.51	3.51
NT 4.0	4.0
2000	5.0
XP	5.1
2003 Serwer	5.2

NTFS 5.1 już na pierwszy rzut oka wygląda inaczej niż FAT32:

Na początku partycji mały boot sector, następnie obszar danych. Po około ~1/3 powierzchni partycji zaczyna się Metadata i MFT, po którym następuje jego rozszerzenie w postaci MFT Zone. Dalsza część schematu przedstawia końcówkę Metadaty, fragment na dane, niewielki folder $MftMirr i główny obszar danych, który zaczna się mniej więcej od połowy partycji.

Jedyną różnicą między partycją dopiero co sformatowanym a przechowującym dane jest brak katalogów i MFT, który podiero powstanie na początku MFT Zone.

• Boot Sector - pełni te same funkcje co Boot Sector w FAT32.
  
• MFT - składa się z 1 KB rekordów. Przechowuje dane dotyczące położenia, nazw i atrybutów wszystkich plików i katalogów dostępnych na partycji. Jeżeli jakiś plik jest wystarczająco mały, aby zmieścić się w rekordzie MFT, tj. z reguły nieco poniżej 1 KB, jest on zapisywany na dysku w pliku MTF. Ten prosty mechanizm pozwala przyspieszyć nieco działanie systemu i aplikacji jak również zaoszczędzić sporo miejsca, zwłaszcza na partycjach z dużym klastrem. Jeżeli w jednym rekordzie zabraknie miejsca na określenie wszystkich atrybutów pliku, system zapisze kolejne rekordy. Struktura rekordu MFT:
  
  
  

  W rekordach MFT poza standardowymi właściwościami są zawarte między innymi dane o prawach dostępu do danego pliku/katalogu i lokalizacja pierwszego i ostatniego klastra fragmentów na których zapisany jest plik. Tablica FAT zawiera jedynie odniesienia do kolejnych rekordów, gdzie znajdują się informaje o kolejnych klastrach.
  

• MFT Zone - Windows XP chcąc zabezpieczyć MFT przed fragmentacją rezerwuje 12.5% przestrzeni partycji. MFT Zone to tylko potencjalnie MFT, może zostać wykorzystany w kilku procentach, może też zostać wykorzystany w całości. Według Microsoftu 12.5% powinno wystarczyć dla partycji, których średnia wielkość plików wynosi 8 KB, czyli dla większości partycji.
  

  MFT Zone zaimuje dużo miejsca na partycji, ale został tak zaprojektowany, aby nie przeszkadzać w normalnym użytkowaniu partycji. Jeżeli skończy się wolna przestrzeń na nowe pliki, Windows automatycznie zmniejszy sektor MFT Zone o połowę.
  

• Metadata - Część MTF, która w NTFS 5.1 została oddzielona od głównego pliku MFT. Mimo to Metadata jest nadal integralną częścią MFT. W skrócie mowiąc Microsoft podzielił MFT na część zawierającą rekordy plików i pozostałe informacje tablicy alokacji. Głównymi składnikami Metadaty są katalogi $LogFile [dziennik używany do przywracania spójności danych] i $Bitmap. $Bitmap jest ciągiem wpisów określających, które klastry na partycji są wolne, a które zapisane. Ponieważ tylko 1 bit odpowiada za 1 klaster, NTFS zawsze błyskawicznie znajduje kolejne wolne klastry. Microsoft twierdzi, że dzięki nowej właściwości system NTFS 5.1 jest szybszy o 5 do 8% od NTFS 5.0. Jest to możliwe zważywszy m.in. na zabezpieczenie kluczowych danych, o zajętości poszczególnych klastrów przed fragmentacją MFT. O ile MFT może ulec fragmentacji, o tyle Metadata jest niemal nie do ruszenia.
  

  Oddzielenie informacji o zajętości klastra od pozostałych danych jest jedną z innowacyjnych cech różniących go od systemów z rodziny FAT.
  

• $MftMirr - jest to kopia 16 pierwszych recordów MFT. W połączenie z journalingiem zabezpiecza MFT przed uszkodzeniem uniemożliwiającym dalsze użytkowanie partycji.
  
• Katalogi [pliki katalogów] - NTFS ma zupełnie inne podejście do struktury katalogów niż FAT32. NTFS tworzy drzewa binarne, w postaci specjalnych plików. Zawierają one odnośniki do odpowiednich rekordów w MFT. Katalogi NTFS są o wiele bardziej rozbudowane niż w systemie FAT32, dlatego są o wiele bardziej wrażliwe na fragmentację. Katalogi są domyślnie tworzone za drugim fragmentem Metadaty. Po zapełnieniu większości powierzchni partycji można je spotkać na całej powierzchni partycji.
  
• Obszar danych - tu zapisywane są pliki.
  

Pierwsze starcie - klastry i rozmiary partycji

Przyjrzyjmy się wielkości klastrów jakie są tworzone podczas formatu partycji.

• Sektor - najmniesza fizyczna część dysku, na której zapisywane są dane w postaci cyfrowej 0, 1. Sektory zawsze mają wielkość 512 B.
  
• Klaster - Logiczna struktura, na której system plików zachowuje pliki. Tylko klaster 512 B składa się z jednego sektora, pozostałe klastry to kilka połączonych sektorów, np. klaster 4 KB, to 8 sektorów.
  

FAT i NTFS inaczej kożystają z klastrów. W FAT32 tylko obszary danych podlegają podziałowi na klastry. Tablice alokacji FAT, a także Boot sectory są podzielone na 512 B sektory. Dlaczego to takie ważne? Tablica FAT jest sztywna - zawsze ma taką samą wielkość zależną jedynie od ilości klastrów jakie musi "obsłużyć".

W NTFS wszystkie zgromadzone dane poza Boot sectorem są plikami. MFT mają nieco inną strukturę, ale to zwykłe pliki, podlegające podziałowi na klastry. Dzięki rezygnacji z podziału tablicy alokacji na sektory, możliwe stało się przeniesienie tych tablic do środkowej części partycji. Będzie to miało ogromne znaczenie dla wszystkich teoretycznych rozważań i zastosowanie w monotoni pracy dysku. MFT jest również bardzo elastyczny. W zależności od potrzeb może zajmować 4 lub 50 MB.

Wielkość partycji	FAT32 klaster	FAT32 wielkość FAT	NTFS klaster
7 MB -32 MB	nieobsługiwane	-	512 B
33 MB - 64 MB	512 B	2 - 4 MB	512 B
65 MB - 128	1 KB	2 - 4 MB	512 B
129 MB -256 MB	2 KB	2 - 4 MB	512 B
257 MB - 512 MB	4 KB	2 - 4 MB	512 B
513 MB–1.024 MB	4 KB	4 - 8 MB	1 KB
1,025 MB - 2 GB	4 KB	8 - 16 MB	2 KB
2 GB - 4 GB	4 KB	16 - 32 MB	4 KB
4 GB - 8 GB	4 KB	32 - 64 MB	4 KB
8 GB - 16 GB	8 KB	32 - 64 MB	4 KB
16 GB - 32 GB	16 KB	32 - 64 MB	4 KB
32 GB - 2 terabytes	nieobsługiwane *	-	4 KB

* XP obsługuje partycji FAT32 większe niż 32 GB [WIndows 98/Me formatowały partycje FAT do 128 GB]. Microsoft specjalnie zabronił systemowi formatować systemem FAT32 partycje większe niż 32 GB, aby zmusić użytkowników do przesiadki na NTFS. I bardzo słusznie, ponieważ FAT32 nie nadaje się do pracy z dużymi partycjami. Wyobraża ktoś sobie skakanie głowicy przez 100 GB danych od tablicy FAT32x na końcu partycji do obrazka na początku partycji?!? Ja wolę sobie tego nie wyobrażać. NTFS może teoretycznie dać sobie radę z partycją 256 TB.

Wielkości klastrów można ustalić samemu, zarówno dla FAT32 jak i NTFS 5.1 jest to od 512B do 64 KB. Należy jednak uwzględnić pewna zastrzeżenie. Klaster o wielkości 64 KB w przypadku FAT32 często sprawia kłopoty aplikacjom i przestają one poprawnie funkcjonować.

• Wielkość klastra nie determinuje tylko ilości zmarnowanej przestrzeni. O wiele ważniejszy jest dla nas rozmiar tablicy alokacji - FAT, a w przypadku NTFS tablica MFT [+Metadata]. Dlaczego jest to taka istotna informacja? Ponieważ tablica alokacji powinna być w całości buforowana w pamięci operacyjnej, aby system plików mógł pokazać pełnię swych możliwości.
  

  Wielkość tablicy FAT łatwo obliczyć. FAT niezależnie od ilości zajętego miejsca na dysku zawsze ma zapisaną całą tablicę. Każdy klaster ma swój 32 B rekord w tablicy alokacji. Jak widać w tabeli wielkość FAT wacha sie od 2 do 64 MB. Ta ostatnia wartość to zdecydowanie za dużo, aby można ją bylo przechowywać w pamięci. Z tego powodu większość tablic alokacji w przypadku większych partycji jest tylko częściowo buforowana w Ram-ie. Nawet zwiększenie rozmiaru klastra niewiele pomagają w przyspieszaniu większych partycji FAT32. Po prostu, im większa partycja, tym odległość między jej początkiem [tablica FAT] a pozostałymi danymi staje się coraz większa. Wadą FAT jest, to że zapisuje informacje nie o plikach, a o klastarch. Określenie klastrów jakie zajmuje plik jest bardzo czasachłonne [rośnie wraz z defragmentacją danych]. Jest to spowodowane dużą ilością odwołań do tablicy FAT. Zanim dane o pliku zostaną zbuforowane w pamięci, muszą najpierw zostać odszukane. O załadowaniu całej tablicy FAT32 do pamięci nie ma mowy! Tylko w przypadku FAT12 jest to praktykowane, gdyż jego tablica ma max. tylko 128 KB.
  

  NTFS dzięki innej konstrukcji może być w całości buforowany w pamięci - ładowane do pamięci są rekordu zawierające informacje o używanych plikach, a nie cała tablica alokacji. Trudno jest określić wielkość MFT na podstawie wielkości klastra. O ile wielkość $Bitmap, zawierającej dane o zajętości poszczególnych klastrów można obliczyć bardzo łatwo 1bit * ilość klastrów = 1 MB dla partycji 32 GB [klaster 4 KB], o tyle wielkość głównej tablicy MFT pozostaje zagadką. W praktyce wykazuje się ona zdecydowanie większą kompaktowością niż tablica FAT. W przypadku NTFS może dojść do bardzo skrajnych sytuacji.
  

  1. Ogromna 100 GB partycja zawierająca jedynie filmy [80 plików po 700 MB] i zbiory mp3 [15000 plików po 3 MB] może mieć MFT zajmującą niecałe 25 MB,
     
  2. Partycja o wielkości 12,5 GB może natomiast mieć większą tablicę MFT:
  
  
  
  

  Taka sytuacja nie jest niczym nadzwyczajnym i można ją łatwo wytłumaczyć. MFT z czasem rośnie. Im więcej plików zapiszemy na dysku, tym więsza staje się tablica MFT, nie zmniejsza swoich rozmiarów. Jeżeli kiedyś było było w nim zapisanych 20.000 1 KB-owych rekordów, a obenie jest mniej, MFT nadal ma wielkość 20.000 rekordów. Systemowy defragmentator znakomicie orientuje się w systuacji. Obecnie zajęte jest ponad 11 tysięcy rekordów [~11 MB]. Cały MFT [tablica alokacji] ma wielkość 45 MB, a więc na partycji było niegdyś zapisane ponad 45.000 rekordów. Analizator obliczył, że obecnie zajęte są 23 procenty MFT. Owe 23% może być buforowane w pamięci RAM. Może, ale nie musi.
  

  Takie rozwiązanie ma swoją wielką zaletę. System NTFS sprawdza się zarówno w przypadku małych jak i wielkich partycji. NTFS poświęca miejsce w MFT tylko dla danych, które znajdują się fizycznie na dysku. Bardzo istotne jest składowanie informacji o plikach, a nie o klastrach. Kompaktowe rekordy MFT mogą zawierać dziesiątki adresów klastrów jakie zajmuje dany plik. W przypadku ogromnych plików np. 500 MB, zajmuje tylko jeden do kilkanastu rekordów, których wprowadzenie do pamięci jest o wiele szybsze, niż w przypadku kilku tysięcy wpisów z tablicy FAT.
  

  Na stałe w pamięci zawsze są buforowane folder $Bitmap i tablica potrzebna do zabezpieczenia danych przed utratą - $LogFile [max 4MB]. Pozostałe matadane są wczytywane sekwencyjnie do pamięci. Tylko informacje o aktualnie używanych plikach [katalogach również] są w pamięci, reszta znajduje się na dysku. Po zamknięciu sesji z danym plikiem jego rekordy są aktualizowane w MFT, katalogach i tablicy $Bitmap na dysku.
  

  "Wadą" stosowania MFT zamiast FAT jest zwiększenie zapotrzebowania na pamięć ze strony systemu NTFS. Daje tu o sobie znać mechanizm ochrony danych i większa liczba atrybutów. Komputery, które pracowały na pierwszych pierwszych Windows NT 3.51 były wyposarzone w kilka MB Ram-u, te z Windows NT 4.0 miały już więcej pamięci, ale raczej nie przekraczały 32 MB. Struktura NTFS była wtedy nieco inna, ale mniejsza o szczegóły. Chodzi o to, że NTFS strasznie mulił te systemy. Stąd między innymi wziąła się opinia o powolności NTFS. Opinia bardzo krzywdząca. Nowa konstrukcja NTFS [od 5.0] potrzebuje 64 MB, aby pokazać pazurki. Nawet jeżeli masz wiele dużych partycji 128 MB daje ogromny zapas, którego z pewniością nie wykorzysta sam NTFS. W gruncie rzeczy jest on bardzo oszczędny i nie wczytuje do pamięci niczego, czego nie musi. Czymże jest ta "wada" w połączeniu z całą masą zalet? Na pudełkach Windows XP i 2000 jest wyraźnie napisane, że te systemy wymagają 128 MB Ram-u do prawidłowego działania. Problem mulenia NTFS znika. W tej sytuacji argument typu - NTFS pożera dużo zasobów, jest niedorzeczny. To, co zabiera dla siebie NTFS 5.x, jest wkalkulowane w narzut systemowy.
  

  Pora na jakiś wniosek: FAT32 sprawdzi się lepiej na komputerach z 2000/XP/2003, które nie mają zalecanych minimum 64 MB pamięci Ram. Obecnie takich maszyn jest niewiele w użyciu. FAT32 jest "lżejszy" a przez to łatwiejszy do udźwignięcia dla starych komputerów. Nowe konstrukcje wyposarzone w min. 512 MB nawet nie zauważą, że NTFS pochłania o kilka MB więcej niż FAT32. Poza tym, liczy się dla nich sprawność dysku, a nie ułamek pamięci.
  

Co wynika z wielkości klastra:

• Utrata miejsca na dysku [zjawisko slack sector-ów] - pliki zapisywane są w klastrach zgodnie z zasadą - jeden klaster = jeden plik. Jeden plik może składać się z wielu klastrów, jeden klaster może zawierać tylko jeden plik. Oznacza to, że jeżeli mamy zapisać plik o wielkości:
  
  
  
  1. 5 KB przy klastrze 4 KB - zapisane zostają dwa klastry, a ostatnie 3 KB drugiego klastra marnuje się
     
  2. 5 KB przy klastrze 8 KB - zapisany zostaje jeden klaster, ostatnie 3 KB marnuje się
  
  

  Zgodnie z tym schematem można dokładnie określić ile KB marnuje się podczas przechowywania określonego pliku na partycji z określonym klastrem. Największe straty występują, gdy zapisujemy małe pliczki na partycjach z dużymi klastarami np. 512 B plik tekstowy na 20 GB partycji FAT32 zajmuje 16 KB. NTFS ma tę zaletę, że przy większym klastrze marnuje mniej miejsca. Przypominam, że pliki niewiele mniejsze niż 1 KB są zapisywane bezpośrednio w tablicy alokacji MFT.
  

  Wielkość klastrów jak wynika z tabeli jest wyraźnie większa w przypadku FAT32 i wynosi 16 KB dla partycji powyżej 16 GB. Tak ogromny klaster wynika z ograniczeń tablic FAT. Natomiast NTFS począwszy od partycji przekraczających 2 GB uparcie zachowuje mały 4 KB klaster, aż do granicy dwóch terabajtów.
  

• "Większy klaster, to lepsza wydajność dysku" (większe partie danych są jednorazowo kopiowane do Ram-u, i mniejsza jest fragmentacji dysku), ale... są i pewne minusy:
  
  
  
  1. Zmiana klastra, to często konieczność sformatowania partycji (Partition Magic 8i Paragon partition Manager pozwalają na zmianę klastra bez formatu dla FAT 32). Windows może również zmienić rozmiar klastra, ale tylko podczas formatowania partycji [Start - Panel Sterowania - Narzędzia Administracyjne - Zarządzanie Komputerem - Zarządzanie dyskami - prawy click na wybranej partycji - formatuj - wybierz odpowiadające Ci ustawienia - OK.]
     
  2. Większy klaster sprawia, że więcej miejsca na dysku się marnuje.
     Zjawisko marnotrawienia przestrzeni na dysku jest tym mniejsze im większe pliki są na nim zapisane.
     
  3. Jeżeli mamy wiele małych plików na partycji o dużym klastrze np. 16 KB, możemy doświadczyć nie wzrostu a spadku wydajności. System odczytuje cały klaster niezależnie od tego, czy jest on wypełniony w całości, czy tylko w części. Nie ma tu znaczenie, czy jest to jedyny klaster, czy ostatni z kilku przypisanych do jednego pliku. Operacje na malutkich plikach trwają dłużej.
  
  

  Przy większym klastrze zmniejszeniu ulegają tablice alokacji. Większe partycje FAT32 znacznie zmniejszą rozmiar tablicy FAT, ale ponieważ tablica znajduje się na początku partycji odległość między nią, a danymi neutralizuje ten "plus". Zwiększanie rozmiaru klastra na małych partycjach mija się natomiast z celem.
  

  W przypadku większych partycji [powyżej 8 GB] warto zastanowić się nad zwiększeniem klastra dla NTFS do poziomu 8 KB. Zmniejszy to znacznie rozmiar nieco rozmiar Metadaty i liczbę recordów w MFT, co poprawi nieco wydajność NTFS. Przy okazji stanie się jeszcze mniej podatny na fragmentację, która rośnie wraz z wielkością partycji. Dla NTFS powiększenie klastra partycji większej niż 8 GB może mieć znaczenie. Pamiętajmy jednak przy tym, że systemowa kompresja nie będzie działać na partycjach z klastem większym niż 4 KB. Jest to bardza ważna informacja, pokazuje dlaczego MS zatrzymał wielkość klastra na poziomie 4 KB! Po prostu nie chciał ograniczać funkcjonalniości nowego systemu plików.
  

  Ostateczne wnioski są proste. Dla partycji NTFS większych niż 8 GB można zwiększyć wielkość klastra do 8 KB, powinno to podnieść ogólną wydajność partycji. Ale zostaniemy trwale pozbawieni możliwości korzystania z kompresji systemowej na tej partycji. Jedynie na partyciach, gdzie większość plików zajmuje mniej niż 4 KB istnieje ryzyko nie uzyskania wzrostu wydajności. W praktyce takie ryzyko niemal nigdy nie występuje.
  

  W pozostałych sytuacjach problem polega na tym, że różnice w wydajności są niewielkie i trudne do zmierzenia. Pewne jest tylko to, że możemy nieco zyskać:
  

  
  
  • Większy klaster to mniejszy poziom fragmentacji, a to z kolei skraca czas defragmentacji. Ma to pewne znaczenie dla wydajności. Taki dysk możemy częściej defragmentować bez dłużącego się oczekawania na efekt końcowy.
    
  • Ustawiając mniejszy klaster niż standardowy, jeżeli na partycji mamy niemal wyłącznie niewielkie pliki o połowę mniejsze niż rozmiar klastra. W praktyce taka sytuacja występuje bardzo żadko. Poza tym należy zauważyć, że podatny na fragmentację i nieprzystosowany do zarządzania tysiącami plików FAT będzie źle znosił przenoszenie i nadpisywanie tych plików. Nieco lepiej zniesie taki zabieg NTFS, który zachowa najmniejsze pliczki bezpośrednio w MFT. Ponieważ obecnie nie pracuje się na dużych kilkutysięcznych zbiorach plików do 2 KB niemal nikt nie odniesie korzyści ze zmniejszenia klastra.
    

    Zapewne niektórzy pomyśleli o zmniejszeniu wielkich klastrów FAT32. Rzeczywiście 16 KB klastry na partycjach po 16-32 GB, to już sporo, ale tak musi zostać. Jeżeli zmniejszyszymy rozmiar klastra o połowę, podwoimy wielkość tablicy FAT, czyli narobimy kłopotów systemowi, który będzie musiał nieustannie przeszukiwać ogromną 64 - 128 MB tablicę położoną na peryferiach partycji. Do tego dochodzi większa fragmentacja danych. Nie warto!
    

  • Ustawiając większy klaster niż standardowy, jeżeli na partycji mamy niemal wyłącznie pliki dwukrotnie większe niż dotychczasowy rozmiar klastra. Taka systuacja zdarza się dosyć często. Oto efekt analizy mojej partycji systemowej, która teoretycznie zawiera wiele małych pliczków:
    
    
    

    Zadziwiający wynik? Średni rozmiar plików na innych partycjach był jeszcze większy. Oczywiście kilkumegabajtowe pliki znacznie zawyrzyły tu statystykę, ale niepodwarzalnym faktem jest, że pliczki poniżej 4 KB to pieśń przeszłości. Jak już wcześniej zostało powiedziane, utratę wydajdości po powiększeniu klastra powoduje konieczność odczytywania całego klastra niezależnie od tego, czy jest on zapisany w całości, czy przez kilka bajtów.
    

    Aby rozważania teoretyczne miały jakikolwiek sens praktyczny będę zastanawiał się nad dwiema sytuacjami:
    

  • 
    

    Partycja systemowa: Jest ona z założenia niewielka, a przynajmniej powinna taka być! Jako ramy przestrzenne przyjmuję rozmiar partycji od 2 GB. Poniżej tej granicy trudno jest bez zdecydowanych cięć utrzymać XP-ka na partycji. Za górną granicę biorę 8 GB. Moim zdaniem jest to absolutnie za dużo, ale niejeden użytkownik ma nawet większą partycję systemową. Zarówna FAT32 jak i NTFS dla partycji 2 - 8 GB domyślnie używają klastra o wielkości 4 KB. Zastanówy się teraz co spowoduje powiększenie klastra do 8 KB.
    

    Dla FAT32, będzie to zmniejszenie o połowę tablicy FAT [do 4 GB - max. 16 MB, do 8 GB - max. 32 MB]. Dla małej partycji przyniesie to korzyści, ponieważ system ma mniej danych do przeszukania, nieco spada też ryzyko fragmentacji. Z minusów należy wymienić utratę kilku MB na slack space w połączeniu z ewentualnym, chwilowym małym spadkiem wydajności.
    

    FAT32, 2 - 4 GB - Teoretycznie wszystko wydaje się więc w porządku. FAT w miarę sprawnie radzi sobie z partycjami o rozmiarze 4 GB. Im mniejsza będzie partycja, tym więcej uda się z niego wycisnąć. Mała tablica alokacji w dużej mierze może zostać załadowana do pamięci, co zredukuje znacząco liczbę odwołań do niej na dysku. Mały rozmiar powoduje również, że odległość między tablicą FAT, a drugim końcem partycji jest niewielki, co jest ważne dla ogólnej wydajności. Prostą konstrukcją sprawia, że małe partycji systemowe oparte o FAT32 są naprawdę szybkie. Taki stan rzeczy w dużej mierze przyczynił się do upowszechnienia opinii o wyższości FAT32 nad NTFS. Niestety, jest tylko przejściowy i nie zawsze gwarantuje przewagę nad NTFS. Szybkość spada wraz ze wzrostem wielkośći partycji systemowej i ilością zapisanych na niej plików. Dają też o sobie znać brak zabezpieczeń przed uszkodzeniem danych. Takie zabezpieczenie to podstawa dla utrzymania systemu w należytym stanie.
    

    Kompaktowość danych trudniej jest zachować ze względu na brak obsługi kompresowania przez FAT - przywracanie systemu ma ustawione ograniczenie do 400 MB [dla partycji do 4 GB], rozpycha się również katalog dllcache, który szybciej niż w NTFS uzyskuje swoje maksymalne 300 MB [brak kompresji], które stanowi 15% powierzchni dla partycji 2 GB i 10% dla 3 GB. Oddając sprawiedliwość FAT32 dodam, że dllcache można opróżnić, a przywracanie systemu wyłączyć. Reasumując - FAT32 na małych partycjach 2 - 4 GB jest szybki. Stosunkowo duży klaster 8 KB, pomaga mu zmniejszyć, jego wielką bolączkę - pojawiającą się z czasem ogromną defragmentację. Ale czy jego przewaga nad NTFS 5.1 jest duża ...? Oddzielenie MFT od Metadaty przyspiesza NTFS 5.1. Celem tej modyfikacji była próba dogonienia FAT32 na małych partycjach. Można powiedzieć, że próba była udana...
    

    FAT32, 4 - 8 GB - Przymuszony FAT32 poradzi sobie i z 8 GB, chociaż z tym jest już gorzej niż z 4 GB. Jest jednak więcej "ale"... O ile rozmiar jeszcze nie spowalnia FAT32, problemy może sprawiać ilość plików zgromadzonych na partycji systemowej. Na dużej partycji są przechowywane większe ilości danych, instaluje się więcej programów. Liczba plików może szybko przekroczyć 20.000, a to już całkiem sporo do zarządzania dla FAT32. Linearne wyszukiwanie plików zaczyna dawać o sobie znać. Ogółem FAT + partycja systemowa powyżej 4 GB nie jest najlepszym pomysłem.
    

    FAT32 powyżej 8 GB - nawet nie próbuj ustawia tak dużej "systemówki" na FAT32, a w zasadzie to już 32x. Ten system plików nie udźwignie tego brzemienia.
    

    Przejdźmy do NTFS. Zwiększenie wielkości klastra do 8 KB spowoduje (poza zwiększeniem slack space) zmniejszenie o połowę tablicy $Bitmap i częściowo MFT i Metadaty. Wpisywanie najmniejszych pliczków bezpośrednio do MFT w pewnym stopniu ograniczy utratę miejsca i ewentualny chwilowy spadek wydajności. Powiększanie partycji od 2 do 8 GB ma dla NTFS znacznie mniejsze znaczenie niż dla FAT. Tablica MFT znajduje się w środkowej części partycji, więc ma wszędzie blisko. Jest to ważne, ponieważ jej rozmiar zależy wyłącznie od liczby plików zapisanych na dysku, a nie od liczby klastrów. Dzięki temu odczytywanie Metadaty i MFT jest stosunkowo szybkie. NTFS ma tą zaletę, że nie przeszkadza mu zwiększanie liczby plików na partycji, jego mechanizmy wyszukiwania wolnych klastrów i poszczególnych plików są bardzo szybkie. Dzięki tym cechom nie musimy obawiać się, że powiększenie partycji systemowej i/lub ilości zapisanych na niej plików spowoduje spadek wydajności. Ogromną zaletą NTFS są mechanizmy zabezpieczające dane, które działają bez jakiegokolwiek niepokojenia użytkownika. Są one bardzo skuteczne. To wielki plus dla partycji na której ma znajdować się Windows.
    

  • Partycja na dane: Nie ma tu nad czy się rozwodzić. Jak już zostało wielokrotnie powiedziane - FAT32 nie radzi sobie z dużymi partycjami. Kiedy był konstruowany teoretyczną granicą dla dysków twardych było 8.4 GB. Widać to w jego architekturze, partycje powyżej 8 GB sprawiają mu sporo problemów. Z kolei NTFS został zaprojektowany z myślą o zarządzaniu wielkimi ilościami danych. Nie stanowi dla niego większej różnicy, czy partycja ma 4, czy 64 GB. Oczywiście, przy tak dużej partycji warto powiększyć jego klaster, ale o tym była już mowa. Najczęściej architektura NTFS będzie lepiej sprawdzać się jako magazyn na dane.
    

    Gdzie jest ta granica oddzielająca partycje szybsze na FAT32, a te na NTFS? Trudno powiedzieć, to zależy od ilości plików na partycji, ich wielkości, częstości modyfikacji plików... Sytuację szybko jednak się wyjaśnia. Obecnie mało kto ma partycje mniejsze niż 4 GB. Poza "systemówką" są to najwyżej małe magazyny o specjalnym przenaczeniu lub partycje na starych, wolnych, małych dyskach [do 10 GB], gdzie lepiej sprawdza się FAT32, ze względu na swą prostotę i mniejsze pochłanianie zasobów PC-ta.