Część 1. Fizyczna struktura ntfs

Zacznijmy od ogólnych faktów. Teoretycznie partycja NTFS może mieć prawie dowolny rozmiar. Oczywiście jest granica, ale nawet jej nie wskażę, bo z marginesem wystarczy na kolejne sto lat rozwoju technologii komputerowej – przy dowolnym tempie wzrostu. Jak to działa w praktyce? Prawie to samo. Maksymalny rozmiar partycji NTFS jest obecnie ograniczony tylko rozmiarem dysków twardych. NT4 będzie jednak miał problemy z instalacją na partycji, jeśli jakakolwiek jej część znajduje się więcej niż 8 GB od fizycznego początku dysku, ale ten problem dotyczy tylko partycji rozruchowej.

Dygresja liryczna. Metoda instalacji NT4.0 na pustym dysku jest dość oryginalna i może prowadzić do nieporozumień dotyczących możliwości NTFS. Jeśli powiesz instalatorowi, że chcesz sformatować dysk na NTFS, maksymalny rozmiar, który zaoferuje, to tylko 4 GB. Dlaczego tak mała, skoro rozmiar partycji NTFS jest praktycznie nieograniczony? Chodzi o to, że sekcja instalacji po prostu nie zna tego systemu plików 🙂

Instalator formatuje ten dysk na zwykły FAT, którego maksymalny rozmiar w NT to 4 GB (przy użyciu niezbyt standardowego dużego klastra 64 KB) i instaluje NT na tym FAT.

Ale już w trakcie pierwszego rozruchu samego systemu operacyjnego (nadal w fazie instalacji) partycja jest szybko konwertowana na NTFS; aby użytkownik niczego nie zauważył, poza dziwnym „ograniczeniem” do rozmiaru NTFS podczas instalacji. 🙂

Struktura sekcji – widok ogólny

Jak każdy inny system, NTFS dzieli całą użyteczną przestrzeń na klastry – bloki danych używane w danym momencie. NTFS obsługuje prawie każdy rozmiar klastra – od 512 bajtów do 64 KB, podczas gdy klaster 4 KB jest uważany za pewien standard. NTFS nie ma żadnych anomalii w strukturze klastrów, więc nie ma wiele do powiedzenia na ten ogólnie dość banalny temat.

Dysk NTFS jest warunkowo podzielony na dwie części. Pierwsze 12% dysku jest przeznaczone na tzw. strefę MFT – przestrzeń, do której rośnie metaplik MFT (o tym poniżej). W tym obszarze nie można zapisywać żadnych danych. Strefa MFT jest zawsze pusta — dzieje się tak, aby najważniejszy plik usługi (MFT) nie ulegał fragmentacji w miarę wzrostu. Pozostałe 88% dysku to zwykła przestrzeń do przechowywania plików.

Wolne miejsce na dysku obejmuje jednak całą fizycznie wolną przestrzeń – tam również znajdują się niewypełnione fragmenty strefy MFT. Mechanizm korzystania ze strefy MFT jest następujący: gdy plików nie można już zapisywać w zwykłym miejscu, strefa MFT jest po prostu zmniejszana (dokładnie dwa razy w obecnych wersjach systemów operacyjnych), zwalniając w ten sposób miejsce do zapisywania plików.

Zwalniając miejsce w zwykłym obszarze MFT, obszar ten może się ponownie rozszerzyć. Jednocześnie nie jest wykluczona sytuacja, gdy w tej strefie również pozostaną zwykłe pliki: nie ma tu żadnej anomalii. Cóż, system próbował zostawić to za darmo, ale to nie zadziałało. Życie toczy się dalej… Metaplik MFT może nadal ulegać fragmentacji, chociaż byłoby to niepożądane.

Mft i jego struktura

System plików NTFS jest wybitnym osiągnięciem strukturyzowania: każdy Elementem systemu jest plik – choćby informacje serwisowe. Najważniejszy plik w systemie NTFS to MFT lub Master File Table – ogólna tabela plików. To on znajduje się w strefie MFT i jest scentralizowanym katalogiem wszystkich innych plików na dysku oraz, paradoksalnie, samego siebie. MFT jest podzielony na rekordy o stałym rozmiarze (zwykle 1 KB), a każdy rekord odpowiada plikowi (w ogólnym znaczeniu tego słowa). Pierwsze 16 plików ma charakter usługowy i jest niedostępnych dla systemu operacyjnego – nazywane są metaplikami, a pierwszym metaplikiem jest sam MFT. Te pierwsze 16 elementów MFT to jedyna część dysku, która ma stałą pozycję. Co ciekawe, druga kopia pierwszych trzech rekordów, dla niezawodności – są one bardzo ważne – jest przechowywana dokładnie na środku dysku. Pozostała część pliku MFT może być zlokalizowana

Metapliki

Pierwsze 16 plików NTFS (metaplików) ma charakter usługowy. Każdy z nich odpowiada za jakiś aspekt systemu. Zaletą takiego podejścia modułowego jest niesamowita elastyczność – na przykład w przypadku FAT fizyczne uszkodzenie samego obszaru FAT jest fatalne w funkcjonowaniu całego dysku, a system NTFS może przesuwać, a nawet fragmentować, całą swoją usługę obszary, omijając wszelkie uszkodzenia powierzchni – z wyjątkiem pierwszych 16 elementów MFT.

Metapliki znajdują się w katalogu głównym dysku NTFS – zaczynają się od znaku „$”, chociaż trudno jest uzyskać o nich jakiekolwiek informacje za pomocą standardowych narzędzi. Co ciekawe, pliki te mają również bardzo realny rozmiar – możesz się dowiedzieć, na przykład, ile system operacyjny wydaje na katalogowanie całego dysku, patrząc na rozmiar pliku $MFT. W poniższej tabeli wymieniono aktualnie używane metapliki i ich przeznaczenie.

 

$MFT	Sam MFT
$MFTmirr	kopia pierwszych 16 rekordów MFT umieszczona na środku dysku
$logfile	plik wsparcia logowania (patrz poniżej)
$Głośność	informacje o usłudze – etykieta woluminu, wersja systemu plików itp.
$AtrDef	lista standardowych atrybutów plików na woluminie
$.	katalog główny
$Mapa bitowa	mapa wolnego miejsca na wolumin
$Boot	sektor rozruchowy (jeśli partycja jest bootowalna)
$Kwota	plik, który rejestruje prawa użytkownika do wykorzystania miejsca na dysku (zaczął działać tylko w NT5)
$wykładanie	plik – tabela powiązań między dużymi i małymi literami w nazwach plików na bieżącym woluminie. Jest to potrzebne głównie dlatego, że w plikach NTFS nazwy zapisywane są w Unicode, czyli 65 tysięcy różnych znaków, bardzo nietrywialne jest szukanie dużych i małych odpowiedników.

Pliki i strumienie

Więc system ma pliki – i tylko pliki. Co obejmuje ta koncepcja w systemie plików NTFS?

• Przede wszystkim obowiązkowym elementem jest wpis w MFT, ponieważ, jak wspomniano wcześniej, wszystkie pliki dyskowe są wymienione w MFT. W tym miejscu przechowywane są wszystkie informacje o pliku, z wyjątkiem rzeczywistych danych. Nazwa pliku, rozmiar, położenie na dysku poszczególnych fragmentów itp. Jeśli brakuje jednego rekordu MFT dla informacji, używanych jest kilka, niekoniecznie jeden z rzędu.

• Element opcjonalny – strumienie danych plików. Definicja „opcjonalnego” może wydawać się dziwna, niemniej jednak nie ma w tym nic dziwnego. Po pierwsze, plik może nie zawierać danych – w tym przypadku nie zajmuje wolnego miejsca na samym dysku. Po drugie, plik może nie być bardzo duży. Wtedy pojawia się dość udane rozwiązanie: dane pliku są przechowywane bezpośrednio w MFT, w miejscu pozostałych danych głównych w jednym rekordzie MFT. Pliki zajmujące setki bajtów zwykle nie mają swojej „fizycznej” postaci w głównym obszarze plików – wszystkie dane takiego pliku są przechowywane w jednym miejscu – w MFT.

Interesująca jest sytuacja z danymi pliku. Ogólnie rzecz biorąc, każdy plik w systemie NTFS ma nieco abstrakcyjną strukturę – nie zawiera danych jako takich, ale są strumienie. Jeden ze strumieni ma dla nas zwykłe znaczenie – dane plikowe. Ale większość atrybutów plików to także strumienie! Okazuje się więc, że plik ma tylko jedną podstawową encję – numer w MFT, a wszystko inne jest opcjonalne. Ta abstrakcja może być użyta do tworzenia całkiem wygodnych rzeczy – na przykład możesz „przykleić” inny strumień do pliku, zapisując w nim dowolne dane – na przykład informacje o autorze i zawartości pliku, jak to ma miejsce w Windows 2000 (prawa zakładka we właściwościach pliku, oglądana z eksploratora). Co ciekawe, te dodatkowe strumienie nie są widoczne w standardowy sposób: obserwowany rozmiar pliku to tylko rozmiar strumienia głównego, który zawiera tradycyjne dane. Możliwe jest na przykład posiadanie pliku o zerowej długości, po usunięciu którego zostanie zwolnione 1 GB wolnego miejsca – po prostu dlatego, że jakiś sprytny program lub technologia utknął w nim dodatkowy strumień (dane alternatywne) o rozmiarze gigabajta . Ale w rzeczywistości w chwili obecnej strumienie praktycznie nie są używane, więc nie należy się bać takich sytuacji, chociaż są one hipotetycznie możliwe. Pamiętaj tylko, że plik w systemie NTFS jest głębszą i bardziej globalną koncepcją niż można sobie wyobrazić tylko przeglądanie katalogów na dysku. I wreszcie: nazwa pliku może zawierać dowolne znaki, w tym pełny zestaw alfabetów narodowych, ponieważ dane są prezentowane w Unicode – 16-bitowej reprezentacji, która daje 65535 różnych znaków. Maksymalna długość nazwy pliku to 255 znaków.

Katalogi

Katalog w systemie NTFS to specyficzny plik, który przechowuje łącza do innych plików i katalogów, tworząc hierarchiczną strukturę danych na dysku. Plik katalogu jest podzielony na bloki, z których każdy zawiera nazwę pliku, podstawowe atrybuty oraz odniesienie do elementu MFT, który już zawiera pełne informacje o elemencie katalogu. Wewnętrzna struktura katalogów to drzewo binarne. Oto, co to oznacza: aby znaleźć plik o podanej nazwie w katalogu liniowym, takim jak na przykład FAT, system operacyjny musi przejrzeć wszystkie wpisy w katalogu, aż znajdzie właściwy. Natomiast drzewo binarne porządkuje nazwy plików w taki sposób, że wyszukiwanie plików odbywa się szybciej – poprzez uzyskanie dwuwartościowych odpowiedzi na pytania o lokalizację pliku. Pytanie, na które drzewo binarne może odpowiedzieć, brzmi: w jakiej grupie, w stosunku do tego elementu, czy nazwa, której szukasz – powyżej czy poniżej? Od takiego pytania zaczynamy do środkowego elementu, a każda odpowiedź zawęża obszar wyszukiwania średnio dwa razy. Pliki, powiedzmy, są po prostu posortowane alfabetycznie, a na pytanie odpowiada się w oczywisty sposób – porównując początkowe litery. Obszar poszukiwań, zawężony dwukrotnie, zaczyna być eksplorowany w podobny sposób, zaczynając ponownie od środkowego elementu.

Wniosek jest taki, że aby wyszukać np. jeden plik spośród 1000, FAT będzie musiał wykonać średnio 500 porównań (najprawdopodobniej plik zostanie znaleziony w połowie wyszukiwania), a system oparty na drzewie tylko około 12 (2^10 = 1024). Oszczędność czasu wyszukiwania jest oczywista. Nie należy jednak myśleć, że w tradycyjnych systemach (FAT) wszystko tak działa: po pierwsze utrzymanie listy plików w postaci drzewa binarnego jest dość pracochłonne, a po drugie nawet FAT w wykonaniu nowoczesnego systemu (Windows2000 lub Windows98) używa podobnego wyszukiwania optymalizacyjnego. To tylko kolejny fakt, który możesz dodać do swojego pola wiedzy. Chciałbym też rozwiać powszechne nieporozumienie (które sam niedawno podzieliłem), że dodanie pliku do katalogu w postaci drzewa jest trudniejsze niż do katalogu liniowego: są to dość porównywalne operacje w czasie – chodzi o to że w celu

Jakie informacje można uzyskać po prostu czytając plik katalogu? Dokładnie to, co produkuje polecenie dir. Aby wykonać najprostszą nawigację po dysku, nie musisz wchodzić do MFT dla każdego pliku, wystarczy przeczytać najbardziej ogólne informacje o plikach z plików katalogów. Główny katalog dysku – root – nie różni się niczym od zwykłych katalogów, z wyjątkiem specjalnego odnośnika do niego od początku metapliku MFT.

Dziennikarstwo

NTFS to system odporny na błędy, który może łatwo przywrócić się do prawidłowego stanu w przypadku niemal każdej rzeczywistej awarii. Każdy nowoczesny system plików opiera się na takiej koncepcji, jak transakcja – czynność, która jest wykonywana całkowicie i poprawnie lub w ogóle nie jest wykonywana. NTFS po prostu nie ma stanów pośrednich (błędnych lub niepoprawnych) – kwant zmiany danych nie może zostać podzielony na przed i po awarii, powodując zniszczenie i zamieszanie – jest albo zatwierdzony, albo anulowany.

Przykład 1: Dane są zapisywane na dysku. Nagle okazuje się, że nie mogliśmy napisać do miejsca, w którym właśnie postanowiliśmy zapisać kolejną porcję danych – fizyczne uszkodzenie powierzchni. Zachowanie NTFS w tym przypadku jest dość logiczne: transakcja zapisu jest cofana w całości – system zdaje sobie sprawę, że zapis nie został wykonany. Miejsce zostaje oznaczone jako nieudane, a dane są zapisywane w innym miejscu – rozpoczyna się nowa transakcja.

Przykład 2: bardziej skomplikowany przypadek – dane są zapisywane na dysku. Nagle huk – wyłącza się zasilanie i system uruchamia się ponownie. Na jakiej fazie zatrzymało się nagrywanie, gdzie są dane, a gdzie bzdury? Z pomocą przychodzi inny mechanizm systemu – dziennik transakcji. Rzecz w tym, że system, zdając sobie sprawę z chęci zapisu na dysk, zaznaczył ten stan w metapliku $LogFile. Podczas przeładowania plik ten jest sprawdzany pod kątem niezakończonych transakcji, które zostały przerwane przez awarię i których wynik jest nieprzewidywalny – wszystkie te transakcje są anulowane: miejsce, do którego został zapisany, jest ponownie oznaczane jako wolne, indeksy i elementy MFT są przywracane do stanu w którym były przed awarią, a system jako całość pozostaje stabilny. Ale co, jeśli wystąpił błąd podczas zapisywania do dziennika? To też jest w porządku: transakcja albo jeszcze się nie rozpoczęła (jest tylko próba zarejestrowania zamiaru jej wykonania), albo już się zakończyła – czyli podejmowana jest próba odnotowania, że ​​transakcja faktycznie została już zakończona. W tym drugim przypadku przy następnym uruchomieniu system sam w pełni zorientuje się, że w rzeczywistości wszystko jest już poprawnie zapisane i nie zwróci uwagi na „niekompletną” transakcję.

Pamiętaj jednak, że logowanie nie jest panaceum, a jedynie sposobem na znaczne ograniczenie liczby błędów i awarii systemu. Jest mało prawdopodobne, że zwykły użytkownik NTFS kiedykolwiek zauważy błąd systemowy lub zostanie zmuszony do uruchomienia programu chkdsk — doświadczenie pokazuje, że NTFS jest przywracany do całkowicie poprawnego stanu nawet podczas awarii podczas bardzo obciążonych momentów aktywności dysku. Możesz nawet zoptymalizować dysk i nacisnąć reset w środku tego procesu – prawdopodobieństwo utraty danych nawet w tym przypadku będzie bardzo niskie. Należy jednak pamiętać, że system odzyskiwania NTFS gwarantuje poprawność systemu plików , a nie danych. Jeśli zapisałeś na dysk i miałeś wypadek, Twoje dane mogą nie zostać zapisane. Cuda się nie zdarzają.

Kompresja

Pliki NTFS mają jeden dość przydatny atrybut – „skompresowany”. Faktem jest, że NTFS ma wbudowaną obsługę kompresji dysku – coś, do czego wcześniej trzeba było używać Stackera lub DoubleSpace. Każdy plik lub katalog pojedynczo może być przechowywany na dysku w postaci skompresowanej — ten proces jest całkowicie przezroczysty dla aplikacji. Kompresja plików ma bardzo dużą szybkość i tylko jedną wielką negatywną właściwość – ogromną wirtualną fragmentację skompresowanych plików, która jednak nikomu nie przeszkadza. Kompresja wykonywana jest w blokach po 16 klastrów i wykorzystuje tzw. „klastry wirtualne” – znowu niezwykle elastyczne rozwiązanie, które pozwala na osiągnięcie ciekawych efektów – np. połowę pliku można skompresować, a połowę – nie. Osiąga się to dzięki

klastry plików od 1 do 43 są przechowywane w klastrach dyskowych począwszy od 400

klastry plików od 44 do 52 są przechowywane w klastrach dyskowych począwszy od 8530 …

Fizyczny układ typowego skompresowanego pliku:

klastry plików od 1 do 9 są przechowywane w klastrach dyskowych począwszy od 400

klastry plików od 10 do 16 nie są nigdzie przechowywane

klastry plików od 17 do 18 są przechowywane w klastrach dyskowych począwszy od 409

klastry plików od 19 do 36 nie są nigdzie przechowywane

Widać, że skompresowany plik ma „wirtualne” klastry, w których nie ma prawdziwych informacji. Gdy tylko system zobaczy takie wirtualne klastry, natychmiast rozumie, że dane z poprzedniego bloku, wielokrotność 16, muszą zostać zdekompresowane, a wynikowe dane po prostu wypełnią wirtualne klastry – to w rzeczywistości cały algorytm .

Bezpieczeństwo

NTFS zawiera wiele sposobów ograniczania praw obiektów – uważa się, że jest to najbardziej zaawansowany system plików ze wszystkich obecnie istniejących. Teoretycznie jest to niewątpliwie prawda, ale w obecnych wdrożeniach system uprawnień jest niestety dość daleki od ideału i reprezentuje sztywny, ale nie zawsze logiczny zestaw cech. Prawa przypisywane do dowolnego obiektu i jednoznacznie respektowane przez system ewoluują – poważne zmiany i uzupełnienia praw dokonywane były już kilkakrotnie, a przez Windows 2000 doszły do ​​całkiem rozsądnego zestawu.

Prawa systemu plików NTFS są nierozerwalnie związane z samym systemem – to znaczy, ogólnie rzecz biorąc, nie muszą być przestrzegane przez inny system, jeśli ma on fizyczny dostęp do dysku. Aby uniemożliwić fizyczny dostęp, Windows2000 (NT5) nadal wprowadził standardową funkcję – zobacz poniżej, aby dowiedzieć się więcej na ten temat. System praw w obecnym stanie jest dość złożony i wątpię, czy mogę powiedzieć ogólnemu czytelnikowi cokolwiek interesującego i użytecznego dla niego w życiu codziennym. Jeśli interesuje Cię ten temat, znajdziesz wiele książek o architekturze sieciowej NT, które opisują go bardziej szczegółowo.

Ten opis struktury systemu plików można uzupełnić, pozostaje opisać tylko kilka po prostu praktycznych lub oryginalnych rzeczy.

Twarde linki

Ta rzecz była w NTFS od niepamiętnych czasów, ale była używana bardzo rzadko – a mimo to: Hard Link ma miejsce, gdy ten sam plik ma dwie nazwy (kilka katalogów plików lub różnych wskaźników katalogów wskazuje na ten sam wpis MFT) . Załóżmy, że ten sam plik ma nazwy 1.txt i 2.txt: jeśli użytkownik usunie plik 1, pozostanie plik 2. Jeśli usunie 2, pozostanie plik 1, czyli obie nazwy, od momentu utworzenia, są całkowicie równe. Plik jest fizycznie usuwany dopiero po usunięciu jego nazwiska.

Dowiązania symboliczne (nt5)

Dużo bardziej praktyczna funkcja pozwalająca na tworzenie katalogów wirtualnych – podobnie jak dyski wirtualne z poleceniem subst w DOS-ie. Zastosowania są dość zróżnicowane: po pierwsze uproszczenie systemu katalogów. Jeśli nie podoba Ci się katalog Documents and settings\Administrator\Documents, możesz połączyć go z katalogiem głównym – system nadal będzie komunikował się z katalogiem o gęstej ścieżce, a Ty – o znacznie krótszej nazwie, całkowicie równoważnej to. Aby utworzyć takie połączenia, możesz użyć programu do połączeń (15 Kb, 36 kb), napisanego przez słynnego specjalistę Marka Russinovicha.Program działa tylko w NT5 (Windows 2000), podobnie jak sama funkcja.

Aby usunąć łącze, możesz użyć standardowego polecenia rd. OSTRZEŻENIE: Próba usunięcia łącza za pomocą Eksploratora lub innych menedżerów plików, które nie rozumieją wirtualnej natury katalogu (np. FAR), spowoduje usunięcie danych, do których odwołuje się łącze! Bądź ostrożny.

Szyfrowanie (nt5)

Przydatna funkcja dla osób, które obawiają się o swoje sekrety, każdy plik lub katalog może być również zaszyfrowany, co uniemożliwia odczytanie go przez inną instalację NT. W połączeniu ze standardowym i prawie niezniszczalnym hasłem do uruchomienia samego systemu, ta funkcja zapewnia wystarczające bezpieczeństwo dla większości wybranych przez Ciebie ważnych danych.

Część 2. Cechy defragmentacji ntfs

Wróćmy do jednego dość interesującego i ważnego punktu – fragmentacji i defragmentacji NTFS. Faktem jest, że sytuacji, jaka rozwinęła się w chwili obecnej z tymi dwoma koncepcjami, w żaden sposób nie można nazwać zadowalającą. Na samym początku stwierdzono, że NTFS nie podlega fragmentacji plików. Okazało się to nie do końca prawdą, a stwierdzenie zostało zmienione – NTFS zapobiega fragmentacji. Okazało się, że to też nie do końca prawda. To znaczy, oczywiście, przeszkadza, ale korzyść z tego jest bliska zeru … Teraz jest już jasne, że NTFS to system, który jak żaden inny jest podatny na fragmentację, bez względu na to, co jest oficjalnie powiedziane. Jedyna rzecz – logicznie rzecz biorąc, nie bardzo cierpi z tego powodu. Wszystkie struktury wewnętrzne są zbudowane w taki sposób, aby fragmentacja nie przeszkadzała w szybkim znajdowaniu fragmentów danych. Ale oczywiście nie chroni to przed fizycznymi konsekwencjami fragmentacji – niepotrzebnymi ruchami głowy. I tak – do przodu iz piosenką…

Do źródła problemu…

Jak wiadomo, system fragmentuje pliki najbardziej, gdy zabraknie wolnego miejsca, gdy trzeba wykorzystać małe dziury pozostałe po innych plikach. Oto pierwsza właściwość NTFS, która bezpośrednio przyczynia się do poważnej fragmentacji.

Dysk NTFS jest podzielony na dwie strefy. Na początku dysku znajduje się strefa MFT – strefa, w której rośnie MFT, Master File Table. Strefa zajmuje co najmniej 12% dysku i nie można w niej zapisywać danych. Odbywa się to tak, że przynajmniej MFT nie jest pofragmentowany. Ale kiedy reszta dysku jest pełna, strefa zmniejsza się dokładnie o połowę :). I tak dalej. Tak więc mamy nie jeden przebieg końca dysku, ale kilka. W rezultacie, jeśli NTFS działa z dyskiem, który jest zapełniony w około 90%, fragmentacja rośnie jak szalona.

Jako efekt uboczny – dysk zapełniony w ponad 88% jest prawie niemożliwy do defragmentacji – nawet defragmentacyjny API nie może przenieść danych do strefy MFT. Może się okazać, że nie będziemy mieli wolnego pola manewru.

Dalej. NTFS działa sam i działa, i nadal fragmentuje – nawet jeśli wolne miejsce jest dalekie od wyczerpania. Ułatwia to dziwny algorytm znajdowania wolnego miejsca do zapisywania plików – drugie poważne zaniedbanie. Algorytm działań dla dowolnego nagrania jest następujący: zabierana jest pewna ilość dysku i zapełniana plikiem do granic możliwości. Co więcej, według bardzo ciekawego algorytmu: najpierw wypełniane są duże dziury, potem małe. Tych. typowa dystrybucja fragmentów plików według rozmiaru na pofragmentowanym NTFS wygląda tak (rozmiary fragmentów):

16 – 16 – 16 – 16 – 16 – [skok do tyłu] – 15 – 15 – 15 – [do tyłu] – 14 – 14 – 14 …. 1 – 1 – 1 -1 – 1…

Tak więc proces idzie do najmniejszych dziur w 1 klastrze, mimo że prawdopodobnie na dysku znajdują się znacznie większe kawałki wolnego miejsca.

Zapamiętaj skompresowane pliki — gdy duże ilości skompresowanych informacji są aktywnie przepisywane do NTFS, powstaje ogromna liczba „dziur” z powodu redystrybucji skompresowanych woluminów na dysku — jeśli jakakolwiek sekcja pliku zaczyna się lepiej lub gorzej kompresować, należy albo usunąć z ciągłego łańcucha i umieścić w innym miejscu, albo dokręcić objętość, pozostawiając za sobą dziurę.

Celem tego wprowadzenia jest wyjaśnienie prostego faktu, że nie można powiedzieć, że NTFS zapobiega fragmentacji plików. Wręcz przeciwnie, radośnie je fragmentuje. Fragmentacja NTFS po pół roku pracy zaskoczy każdą osobę znającą pracę systemu plików. Dlatego musisz uruchomić defragmentator. Ale wszystkie nasze problemy nie kończą się na tym, ale, niestety, dopiero się zaczynają…

Rozwiązania?

NT ma standardowe API defragmentacji. Ma interesujące ograniczenie dotyczące przenoszenia bloków plików: można przenosić co najmniej 16 klastrów na raz (!), a te klastry muszą zaczynać się od pozycji będącej wielokrotnością 16 klastrów w pliku. Ogólnie rzecz biorąc, operacja prowadzona jest wyłącznie na 16 klastrach. Konsekwencje:

1. Nic nie da się przenieść do wolnej przestrzeni mniejszej niż 16 klastrów (poza plikami skompresowanymi, ale na razie nie są to ciekawe subtelności).

2. Plik, przenoszony do innej lokalizacji, pozostawia (w nowej lokalizacji) „tymczasowo zajmowaną przestrzeń”, która uzupełnia go w rozmiarze do wielokrotności 16 klastrów.

3. Kiedy próbujesz przenieść plik jakoś niepoprawnie („nie wielokrotność 16”), wynik jest często nieprzewidywalny. Coś jest zaokrąglone, coś się po prostu nie rusza… Niemniej jednak cała scena jest hojnie rozrzucona przez „czasowo zajętą ​​przestrzeń”.

„Tymczasowo zajęte miejsce” służy do ułatwienia odzyskiwania systemu w przypadku awarii sprzętu i jest zwalniane po pewnym czasie, zwykle około pół minuty.

Niemniej jednak logiczne byłoby użycie tego interfejsu API, ponieważ istnieje. I używają tego. Dlatego standardowy proces defragmentacji, dostosowany do ograniczeń API, składa się z następujących faz (niekoniecznie w tej kolejności):

• Wyodrębnianie plików ze strefy MFT. Nie celowo – po prostu nie da się ich tam wsadzić 🙂 Faza nieszkodliwa, a nawet coś pożytecznego.

• Defragmentacja plików. Niewątpliwie przydatny proces, nieco jednak komplikowany przez ograniczenia dotyczące wielości ruchów – pliki często trzeba przenosić mocniej, niż byłoby to logiczne, aby zrobić to mądrze.

• Defragmentacja MFT, maszyn wirtualnych (pagefile.sys) i katalogów. Jest to możliwe przez API tylko w Windows2000, w przeciwnym razie – przy ponownym uruchomieniu, przez osobny proces, jak w starym Diskeeperze.

• Składanie plików bliżej początku to tak zwana defragmentacja wolnego miejsca. To naprawdę straszny proces.

Powiedzmy, że chcemy umieścić pliki w rzędzie na początku dysku. Zamieszczam jeden plik. Pozostawia ogon użycia dodatku do wielokrotności 16. Dokładamy następny – oczywiście po ogonie. Po pewnym czasie, po uwolnieniu ogona, mamy dziurę o wielkości <16 skupisk. Których wtedy nie można wypełnić za pomocą interfejsu API do defragmentacji! W rezultacie przed optymalizacją obraz wolnej przestrzeni wyglądał tak: wiele otworów mniej więcej tej samej wielkości. Po optymalizacji – jedna dziura na końcu dysku i wiele małych <16 klastrów dziur w obszarze wypełnionym plikami. Które miejsca zapełnią się jako pierwsze? Zgadza się, małe dziury bliżej początku dysku <16 klastrów… Każdy plik gładko utworzony na pro-zoptymalizowanym dysku będzie składał się z dzikiej liczby fragmentów. Tak, dysk można następnie ponownie zoptymalizować. A potem znowu… i znowu… I tak – najlepiej co tydzień. Zachwycać się? Rzeczywistość.

Tak więc istnieją dwie w przybliżeniu równoważne opcje. Pierwszym jest częste optymalizowanie dysku takim defragmentatorem, przy jednoczesnym pogodzeniu się z dziką fragmentacją nowo tworzonych plików. Druga opcja to w ogóle niczego nie dotykać i pogodzić się z jednolitą, ale znacznie słabszą fragmentacją wszystkich plików na dysku.

Jak dotąd jest tylko jeden defragmentator, który ignoruje defragmentację API i działa w jakiś sposób bardziej bezpośrednio – Norton Speeddisk 5.0 dla NT. Kiedy próbują porównać to ze wszystkimi innymi – Diskeeper, O&O defrag itp. – nie wspominaj o tej głównej, najbardziej fundamentalnej różnicy. Po prostu dlatego, że ten problem jest starannie ukryty, a przynajmniej nie reklamowany na każdym kroku. Speeddisk to jedyny dotychczas program, który może całkowicie zoptymalizować dysk bez tworzenia małych pustych kawałków wolnego miejsca. Warto też dodać, że przy użyciu standardowego API nie da się defragmentować woluminów NTFS z klastrem większym niż 4 KB, ale SpeedDisk też to potrafi.

Niestety, w systemie Windows 2000 został umieszczony defragmentator, który działa poprzez API iw związku z tym generuje dziury <16 klastrów. Więc jak tylko się pojawi (jeśli jeszcze się nie pojawił), powinieneś natychmiast pobrać Speeddisk dla W2k.

Jako jeden wniosek z tego wszystkiego: wszystkie inne defragmentatory są po prostu szkodliwe, gdy są używane raz. Jeśli uruchomiłeś go przynajmniej raz – musisz uruchomić go co najmniej raz w miesiącu, aby pozbyć się fragmentacji nowo napływających plików. To jest główna istota trudności w defragmentacji NTFS za pomocą środków, które rozwinęły się historycznie.

Część 3. Co wybrać?

Każdy z prezentowanych obecnie systemów plików ma swoje korzenie w głębokiej przeszłości – sięgającej lat 80-tych. Tak, NTFS, choć może się to wydawać dziwne – bardzo stary system! Faktem jest, że przez długi czas komputery osobiste korzystały wyłącznie z systemu operacyjnego DOS, który swój wygląd zawdzięcza systemowi FAT. Ale równolegle rozwijano i cicho funkcjonowały systemy nastawione na przyszłość. Dwa takie systemy, które jednak zyskały szerokie uznanie – NTFS, stworzony dla systemu operacyjnego Windows NT 3.1 w niepamiętnych czasach, oraz HPFS – wierny towarzysz OS / 2.

Wprowadzenie nowych systemów było trudne – jeszcze w 95 roku, wraz z wydaniem Windows95, nikt nie myślał, że coś trzeba zmienić – FAT otrzymał drugi wiatr dzięki naklejonej na górze łatce „długie nazwy”, której wdrożenie tam, choć blisko idealnie możliwego bez zmiany systemu, ale nadal dość głupio. Ale w następnych latach potrzeba zmian wreszcie dojrzała, ponieważ naturalne ograniczenia FAT zaczęły być odczuwalne. FAT32, który pojawił się w Windows 95 OSR2, po prostu przesunął granice – nie zmieniając istoty systemu, co po prostu nie pozwala na zorganizowanie wydajnej pracy z dużymi ilościami danych.

HPFS (High Performance File System), nadal aktywnie wykorzystywany przez użytkowników OS/2, okazał się dość udanym systemem, ale miał też istotne wady – całkowity brak narzędzi do automatycznego odzyskiwania, nadmierną złożoność organizacji danych i małą elastyczność .

Z drugiej strony NTFS nie mógł przez długi czas podbijać komputerów osobistych, ponieważ do organizacji efektywnej pracy z jego strukturami danych potrzebne były znaczne ilości pamięci. Systemy z 4 lub 8 MB (standard 95-96) po prostu nie były w stanie uzyskać żadnej przewagi z NTFS, więc zyskały niezbyt poprawną reputację jako system powolny i nieporęczny. W rzeczywistości nie jest to prawdą – nowoczesne systemy komputerowe z ponad 64 MB pamięci po prostu uzyskują ogromny wzrost wydajności dzięki korzystaniu z NTFS.

Ta tabela podsumowuje wszystkie istotne zalety i wady systemów powszechnych w naszych czasach, takich jak FAT32, FAT i NTFS. Dyskusja o innych systemach jest mało rozsądna, ponieważ obecnie 97% użytkowników wybiera pomiędzy Windows98, Windows NT4.0 i Windows 2000 (NT5.0), a innych opcji po prostu nie ma.

	TŁUSZCZ	FAT32	NTFS
Systemy, które to obsługują	DOS, Windows9X, NT wszystkie wersje	Windows98, NT5	NT4, NT5
Maksymalny rozmiar woluminu	2 GB	praktycznie nieograniczony	praktycznie nieograniczony
Maks. liczba plików na woluminie	około 65 tys.	praktycznie nieograniczony	praktycznie nieograniczony
Nazwa pliku	z obsługą długich nazw – 255 znaków, systemowy zestaw znaków	z obsługą długich nazw – 255 znaków, systemowy zestaw znaków	255 znaków, dowolne znaki dowolnych alfabetów (65 tys. różnych stylów)
Możliwe atrybuty pliku	Zestaw podstawowy	Zestaw podstawowy	cokolwiek przychodzi na myśl twórcom oprogramowania
Bezpieczeństwo	Nie	Nie	tak (od NT5.0 wbudowana jest możliwość fizycznego szyfrowania danych)
Kompresja	Nie	Nie	TAk
Tolerancja błędów	średni (system jest zbyt prosty i dlatego nie ma nic specjalnego do złamania :))	zły (środki optymalizacji prędkości doprowadziły do ​​pojawienia się słabych punktów pod względem niezawodności)	pełne – automatyczne przywracanie systemu w przypadku jakichkolwiek awarii (nie licząc fizycznych błędów zapisu, gdy jeden jest zapisywany, a inny jest zapisywany)
Gospodarka	minimalny (ogromne rozmiary klastrów na dużych dyskach)	ulepszone dzięki zmniejszeniu rozmiarów klastrów	maksymalny. Bardzo wydajny i wszechstronny system przechowywania
Wydajność	wysoki dla małej liczby plików, ale szybko spada wraz z pojawieniem się dużej liczby plików w katalogach. wynik – dla słabo wypełnionych dysków – maksymalny, dla wypełnionych dysków – zły	całkowicie podobny do FAT, ale na dużych dyskach (dziesiątki gigabajtów) zaczynają się poważne problemy z ogólną organizacją danych	system nie jest zbyt wydajny w przypadku małych i prostych partycji (do 1 GB), ale praca z ogromnymi macierzami danych i imponującymi katalogami jest zorganizowana tak wydajnie, jak to możliwe i znacznie przewyższa inne systemy szybkością

Chciałbym powiedzieć, że jeśli twój system operacyjny to NT (Windows 2000), to używanie dowolnego systemu plików innego niż NTFS oznacza znaczne ograniczenie wygody i elastyczności samego systemu operacyjnego. NT, a zwłaszcza Windows 2000, jest jak dwie części jednej całości z NTFS – wiele przydatnych funkcji NT jest bezpośrednio związanych z fizyczną i logiczną strukturą systemu plików, a użycie FAT lub FAT32 ma sens tylko dla kompatybilność – jeśli masz za zadanie odczytać te dyski z innych systemów.