r13-07, ## Documents ##, Windows 2000 Server. Vad. prof

Rozdział 13.
Zarządzanie systemami plików

Zanim zostałem informatykiem, pracowałem jako operator w elektrowni jądrowej i byłem marynarzem na okręcie podwodnym. Wbrew temu, co można przeczytać w powieściach Toma Clancy'ego, w czasach zimnej wojny okresy zmagań o utrzymanie bezpieczeństwa dla demokracji przeplatały się z okresami spokoju. Nie myślcie jednak, że gdy było spokojnie, marynarze-profesjonaliści marnowali swój cenny czas oglądając filmy czy grając w bezika. Nieliczne wolne chwile spędzaliśmy zadając sobie wzajemnie pytania dotyczące działania elektrowni jądrowej, projektowania okrętów podwodnych i procedur bojowych. (No dobrze, może graliśmy troszeczkę w --> bezika[Author:E] ).

W trakcie tych testów ulubione pytanie brzmiało następująco: „Prześledź drogę kropli wody z oceanu poprzez rdzeń reaktora i z powrotem i opisz działanie każdego elementu, przez który przechodzi.” Ktoś, kto potrafił odpowiedzieć na to pytanie, dokładnie znał systemy okrętu. Ktoś, kto potrafił odpowiedzieć na to pytanie jednocześnie zwyciężając w grze w bezika, był wybitnym specjalistą.

Podobnie można bawić się przy projektowaniu systemu plików, na przykład podążając za bajtem od twardego dysku do monitora i opisując każdy sterownik, który napotyka na drodze. Jako administratorzy nie musimy znać odpowiedzi na tego rodzaju pytania na poziomie wymaganym od projektanta systemu lub sprzętu komputerowego, ale znajomość przynajmniej budowy systemu plików może być bardzo przydatna. Pomaga przewidywać problemy, tworzyć plany na wypadek awarii i wykrywać dziwne zachowania.

W poprzednim rozdziale opisano, w jaki sposób Menedżer Dysku Logicznego (Logical Disk Manager — LDM) przygotowuje dysk na potrzeby systemu plików. Po zakończeniu działania LDM dysk jest w „stanie surowym”, więc Windows 2000 za pomocą sterowników Installable File System (IFS) zamienia go na nadający się do zapisu i odczytu danych w użytecznym formacie. A oto lista sterowników IFS sterujących dostępem do danych przechowywanych na dysku twardym:

FASTFAT.SYS. Sterownik FAT (obsługuje również FAT32),
NTFS.SYS. System plików Windows NT,
CDFS.SYS. System plików CD-ROM. Obsługuje płyty CD-ROM w formacie ISO 9660 z długimi nazwami plików o długości maksymalnej do 32 znaków,
UDF.SYS. Sterownik systemu plików Universal Disk Format. System ten obsługuje napędy DVD z plikami o standardowych nazwach długich,
PINBALL.SYS. Sterownik systemu plików HPFS, używanego przez system operacyjny OS/2. Ten system plików nie jest już obsługiwany przez systemy NT,
EFS.SYS. Sterownik szyfrowania plików systemu plików NTFS (Encrypting File System),
RSFILTER.SYS. Sterownik plików archiwalnych (Remote Storage System). Jest to system plików zapewniający niemal natychmiastowy dostęp do plików zapisanych na taśmie.

Szczegółowy opis wymienionych wyżej sterowników IFS nie mieści się w zakresie niniejszej książki. Zainteresowanym polecam książkę Edwarda Dekkera i Josepha Newcomera Developing Windows NT Device Drivers.

Pomijając zawiłości projektowania sterowników dla systemu plików, pewne typowe aspekty ich działania uzasadniają zainteresowanie nimi administratorów systemu. Rozdział niniejszy zawiera szczegółowy opis trzech głównych systemów plików Windows 2000: FAT16, FAT32 i NTFS, podając praktyczne zalety i ograniczenia każdego z nich. Opisano również krok po kroku następujące zagadnienia:

Kompresja dysku i obsługa zapisywania na dysku plików o dużych rozmiarach (Sparse Files),
Dynamiczny wskaźnik lokalizacji danych (Reparse Points) i katalogi dołączania (Mount Points),
Obsługa połączeń rozproszonych (Distributed Link Tracking),
Defragmentacja dysku,
Odporność na błędy, śledzenie dziennika zdarzeń i nowego dziennika zmian (Change Journal),
Przydzielanie użytkownikom ograniczeń wolnej przestrzeni na zasobach dyskowych (Quota Management),
Usługi archiwizacji plików (Remote Storage Services).

Przegląd systemów plików Windows 2000

Z systemami plików związane są następujące pojęcia:

Sektory i jednostki alokacji. Jest to podstawowy podział danych na dysku. Sektory są określone poprzez geometrię dysku i ustalone przez producenta najczęściej jako 512-bajtowe. Jednostka alokacji jest to logiczne połączenie sektorów w większą strukturę, co poprawia wydajność systemu plików.
Partycje i woluminy. Logiczny podział dysku lub zestawu dysków tworzący granice dla systemu plików. W poprzednim rozdziale dokonano rozróżnienia na partycję i wolumin, ponieważ jest to istotne dla działania Menedżera Dysków Logicznych (Logical Disk Manager — LDM), jednak na poziomie abstrakcji reprezentowanym przez system plików, pojęcia te są równoznaczne.
Sektor rozruchowy (Boot Sector). Pierwszy sektor partycji zawierający informacje o systemie plików oraz kawałek programu ładującego.
Blok parametrów BIOS (BIOS Parameter Block — BPB). Fragment sektora rozruchowego zawierający informacje właściwe systemowi plików na danej partycji.
Tablica alokacji plików (FAT). Mapa jednostek alokacji zawierających pliki. Standardowa tablica FAT używa adresów 16-bitowych. W celu zwiększenia pojemności tablica FAT systemu plików FAT32 używa adresów 32-bitowych.
Główna tablica plików (Master file table — MFT). Obiektowa baza danych stosowana w systemie plików NTFS.
Katalogi. Spis nazw plików tworzący hierarchiczną strukturę systemu plików.

Indeksy dodatkowe. NTFS umożliwia indeksowanie dowolnego atrybutu w bazie MFT. Budowa i działanie tych indeksów stanowią znaczną część opisu dodatkowych właściwości systemu plików zamieszczonego w niniejszym rozdziale.

Poniżej przedstawiono charakterystykę wyżej wymienionych elementów i na tej podstawie sporządzono porównanie trzech rodzimych systemów plików Windows 2000: FAT, FAT32 i NTFS pod względem funkcjonalności. Na końcu każdego podrozdziału znajduje się streszczenie podanych informacji.

Sektory i jednostki alokacji

Dane na twardym dysku zapisywane są w sektorach, po 512 bajtów każdy, tworzących koncentryczne ścieżki. Na dysku o pojemności 10 GB, sformatowanym jako jeden wolumin znajduje się w przybliżeniu 20 milionów sektorów.

Numerowanie i śledzenie tak dużej liczby sektorów może być dla systemu plików zadaniem przekraczającym jego możliwości. W celu poprawienia wydajności, sektory zostały połączone w grupy zwane jednostkami alokacji (clusters).

Rozmiar jednostki alokacji podaje liczbę sektorów w tej jednostce, na przykład rozmiar jednostki alokacji równy 8 sektorów oznacza, że w każdej z nich zapisane są 4 kB danych. Jeśli plik nie zapełni całkowicie jednej lub kilku jednostek alokacji, to pozostała część powierzchni dyskowej jest tracona, tak więc najefektywniejsze jest utworzenie jednostek alokacji o rozmiarze jednego sektora.

Stopień wykorzystania dysku maleje wraz ze wzrostem rozmiaru jednostki alokacji. Wszystkie systemy plików Windows 2000 zawierają rozwiązania kompromisowe pomiędzy efektywnym wykorzystaniem dysku, a wydajnością.

FAT

Standardowy system plików FAT wykorzystuje adresowanie 16-bitowe, co ogranicza maksymalną liczbę jednostek alokacji do 2¹⁶ czyli do --> 65 535[Author:UP] . Gdyby rozmiar jednostki alokacji woluminu FAT wynosił jeden sektor, wtedy wolumin ten mógłby zawierać nie więcej niż 65536×512 bajtów, czyli 32 MB. Jeśli wolumin FAT jest większy niż 32 MB, system plików zwiększa rozmiar jednostki alokacji.

Ograniczenia pamięci w trybie rzeczywistym nakładają także ograniczenia na rozmiar jednostki alokacji systemu FAT dla DOS i Windows 9x, który wyraża się potęgą 2 mniejszą od maksymalnej wartości adresu, a zatem wynosi on 2¹⁵ bajtów, czyli 32 kB. Stąd maksymalny rozmiar partycji FAT dla DOS i Windows 95 to --> 65535[Author:UP] ×32 kB lub inaczej około 2 GB. FAT dla Windows 2000, dzięki adresowaniu pamięci w trybie chronionym, ma górną granicę rozmiaru jednostki alokacji równą 2¹⁶ czyli 64 kB.

Wolumin FAT dla Windows 2000 może urosnąć do 4 GB, ale jeśli rozmiar jednostki alokacji tego woluminu będzie większy niż 32 kB, DOS i Windows 95 nie będą miały do niego dostępu. Należy o tym pamiętać w przypadku komputera z możliwością wyboru systemu operacyjnego przy starcie (dual-boot). Z tej samej przyczyny program instalacyjny NT przyjmuje 2 GB jako wartość domyślną rozmiaru woluminu. Wykorzystując opcję ExtendPartition w trybie instalacji bezdotykowej (Unattended Install) możliwe jest zwiększenie tej wartości do 4 GB. Windows 2000 pozwala na utworzenie partycji systemowych większych niż 2 GB pierwszy raz formatując dysk z zastosowaniem systemu plików FAT32.

FAT32

Microsoft wprowadził system plików FAT32 w Windows 95 OSR2. System ten wykorzystuje trzydziestodwubitową tablicę FAT powiększając maksymalny rozmiar pliku do 2³² bajtów, czyli około 4 GB. DOS Windows95 i NT nie mogą odczytywać ze standardowej partycji FAT32. Do zaadresowania jednostki alokacji w tym systemie plików stosuje się obcięty adres 32-bitowy z niewykorzystanymi najstarszymi czterema bitami i dlatego wolumin FAT32 może zawierać 2²⁸ jednostek alokacji.

Najmniejsza jednostka alokacji wyżej wymienionego systemu plików zawiera 4 kB, największa zaś 32 kB. Teoretycznym ograniczeniem górnym rozmiaru woluminu FAT32 jest 8 TB, praktyczne ograniczenie to liczba 2³² sektorów, czyli 2 TB, na jednym dysku lub macierzy dysków. Windows 2000 obniża tę wartość jeszcze bardziej, maksymalny rozmiar woluminu FAT32 dla Windows 2000 wynosi 32 GB, co umożliwia zapis całej tablicy FAT w pamięci podręcznej poprawiając wydajność systemu.

NTFS

W systemie plików NT zastosowano adresowanie 64-bitowe, co daje teoretyczny rozmiar pojedynczego pliku równy 2⁶⁴ bajtów czyli około 16 --> exabajtów[Author:UP] , ale jak już wspomniano wcześniej, w praktyce stosuje się ograniczenie maksymalnego rozmiaru woluminu do 2 TB.

Podsumowanie

Oto najważniejsze informacje do zapamiętania o wykorzystywaniu sektorów i jednostek alokacji przez trzy wyżej wymienione systemy plików:

Maksymalny rozmiar jednostki alokacji systemu plików FAT wynosi 32 kB.
Maksymalny rozmiar partycji FAT dla DOS i Windows 95 to 2 GB.
Maksymalny rozmiar partycji FAT dla Windows 2000 wynosi 4 GB. DOS i Windows 95 nie mają dostępu do partycji większych niż 2 GB.
Windows 2000 umożliwia tworzenie partycji systemowych większych niż 2 GB poprzez pierwsze sformatowanie dla systemu plików FAT32.
Maksymalny rozmiar woluminu FAT32 wynosi 8 TB, ale w praktyce stosuje się woluminy do 2 TB.
Windows 2000 ogranicza rozmiar woluminów FAT32 do 32 GB.
Maksymalny rozmiar woluminu NTFS, który teoretycznie może wynosić 16 --> eksabajtów[Author:UP] , w praktyce ograniczony jest do 2 TB.

Sektor rozruchowy partycji (Boot sector) i blok parametrów BIOS (BPB)

W poprzednim rozdziale opisano, w jaki sposób LDM przygotowuje cały dysk lub jego część dla systemu plików. LDM może również połączyć kilka dysków w jeden wolumin logiczny. System plików, formatując taki wolumin, pozostawia pierwszy sektor wolny, przeznaczając go dla specjalnej struktury nazwanej sektorem rozruchowym partycji (Partition Boot Sector) lub w skrócie sektorem rozruchowym (boot sector), nawet jeśli partycja nie jest partycją rozruchową. Sektor rozruchowy zawiera informacje o systemie plików i strukturach danych systemu.

Program ładujący (bootstrap loader)

Zawartość sektora rozruchowego jest zależna od zastosowanego systemu plików, jednakże kilka pierwszych pozycji jest wspólnych dla wszystkich. Poniższy wydruk przedstawia pierwsze 16 bajtów sektora rozruchowego FAT:

<<Pierwsze 16 bajtów sektora rozruchowego>>

EB 3C 90 4D 53 44 4F 53 2E 30 00 02 04 01 00 .<.MSDOS5.0.....

Pierwsze trzy bajty sektora rozruchowego zawierają instrukcję skoku do jego fragmentu, w którym mieści się program rozpoczynający ładowanie systemu (bootstrap loader). Program ten jest na tyle dobry, aby znależć i wywołać program ładujący (secondary bootstrap loader) rozpoczynający sekwencję startową systemu operacyjnego. Dla DOS i Windows 9x jest to IO.SYS a dla NT i Windows 2000 -- NTLDR. Komputery z procesorem Alpha nie mają sektora rozruchowego, ścieżka ARC zapisana w pamięci ROM pozwala na wyszukanie programu ładującego OSLOADER.

Następne 8 bajtów sektora rozruchowego zawiera nazwę wykorzystywanego systemu plików oraz, opcjonalnie, jego wersję. Windows 2000 używa nazwy MSDOS 5.0 zarówno dla systemu plików FAT, jak i dla FAT32, zapewniając poprawną pracę starszych aplikacji, które sprawdzają system plików i jego wersję. Co prawda w Windows 2000 można użyć polecenia SETVER w trybie wirtualnej maszyny DOS (Virtual DOS Machine - VDM), ale po co zmuszać administratora do marnowania czasu, skoro można uniknąć problemu podając przy rozruchu nieprawdziwe informacje o systemie plików i jego wersji.

Od bajtu nr 12 zaczynają się: blok parametrów BIOS (BIOS Parameter Block - BPB) i rozszerzony blok parametrów BIOS (Extended BPB). Ich zawartość zależy od systemu plików.

BPB dla systemu plików FAT

BIOS Parameter Block na partycji FAT ma 25 bajtów. Następujące po nim 26 bajtów tworzy Extended BPB. Poniżej przedstawiono obydwie struktury oraz opis ich zawartości. W komputerach z procesorami Intela dane zapisywane są w kolejności: młodszy bajt-starszy bajt, dlatego aby otrzymać właściwą wartość słowa lub podwójnego słowa, należy odwrócić kolejność bajtów. Np. 00 02 to w zapisie szesnastkowym 0200 lub w zapisie dziesiętnym 512.

<<BPB i rozszerzony BPB woluminu FAT16. Zamieszczono również pierwsze 11 bajtów sektora rozruchowego.>>

EB 3C 90 4D 53 44 4F 53 35 2E 30 00 02 04 01 00 .<.MSDOS5.0.....

02 00 02 00 00 F8 C8 00 20 00 40 00 20 00 00 00 ........ .@. ...

E0 1F 03 00 80 00 29 20 24 ED 64 4E 4F 20 4E 41 ......) $.Dn0 NA

4D 45 20 20 20 20 46 41 54 31 36 20 20 20 33 C9 ME FAT16 3.

Liczba bajtów w sektorze (00 02). W zapisie szesnastkowym 200h, w zapisie dziesiętnym 512. Większość dysków ma sektory 512-bajtowe.
Liczba jednostek alokacji w sektorze (04). W zapisie szesnastkowym 4h, w zapisie dziesiętnym 4. Przy 512 bajtach w sektorze daje to 2048 bajtów w jednostce alokacji. Jest to partycja 100 MB, niewielka jak na dzisiejsze standardy. Ograniczenie przestrzeni adresowej systemu plików FAT jest przyczyną nieekonomicznego wykorzystywania dysku twardego.
Liczba sektorów rezerwowych poprzedzających tablicę alokacji plików FAT (01 00). W zapisie szesnastkowym 0001h, w zapisie dziesiętnym 1. Liczba ta mówi, że pomiędzy początkiem danej partycji a początkiem tablicy alokacji plików FAT znajduje się jeden sektor. Ponieważ wielkość sektora rozruchowego wynosi jeden, więc tablica FAT zaczyna się zaraz za nim. Takie położenie tablicy FAT jest wymuszone przez system plików FAT16 i jest to jedna z kluczowych słabości tego systemu. Lokalizacja tablicy FAT, niezmienna w stosunku do sektora rozruchowego, czyni ją podatną na zniszczenie w przypadku uszkodzenia sektora, w którym jest umieszczona, ogranicza także elastyczność systemu plików FAT pod względem zapisu dodatkowych metadanych (metadata).
Liczba kopii tablicy FAT (02). W każdej partycji FAT16 zapisane są dwie wersje tablicy FAT: oryginał i kopia. System plików, nie mogąc odczytać jakiejkolwiek pozycji z pierwotnej tablicy FAT, ratuje się sięgając do jej kopii. W takiej sytuacji sterownik FASTFAT Windows 2000 zapisuje do dziennika zdarzeń (Event Log) komunikat o błędzie. System plików FAT nie ma możliwości przeniesienia tablicy FAT do nieuszkodzonego sektora. Jeśli sterownik systemu plików informuje o wystąpieniu błędów odczytu lub zapisu pierwotnej tablicy FAT, należy jak najszybciej ponownie sformatować dysk i odtworzyć dane z kopii zapasowej.
Maksymalna liczba pozycji w głównym katalogu systemowym (root directory)(00 02). W zapisie szesnastkowym 200h, w zapisie dziesiętnym 512. Katalog ten w przypadku systemu plików FAT16 ma stały rozmiar, ograniczający liczbę pozycji do 512. Stanowi to problem przy długich nazwach plików, ponieważ każde 13 dodatkowych znaków nazwy stanowi kolejną pozycję w katalogu systemowym.
Liczba sektorów (00 00). Nazywana jest czasami liczbą małych sektorów (small sector value) i używana tylko dla partycji 32 MB lub mniejszej. Umożliwia bezpośrednie numerowanie 2¹⁶ sektorów w przypadku, gdy rozmiar jednostki alokacji równy jest jednemu sektorowi, jak to miało miejsce dla DOS 3.0 lub wersji wcześniejszych. Dla partycji powyżej 32 MB w pozycji tej wpisane jest zero.
Deskryptor mediów (F8). F8 oznacza dysk twardy, w tym również wyjmowany. Dyskietkom przyporządkowano inne wartości.
Liczba sektorów zajętych przez tablicę FAT (C8 00). W zapisie szesnastkowym 00C8h, w zapisie dziesiętnym 200 sektorów. Przy rozmiarze sektora równym 512 bajtów daje to 100 kB. Należy jeszcze podwoić tę liczbę ze względu na kopię tablicy FAT. Stosunek obszaru dysku zajętego przez system plików do wielkości partycji wynosi w przybliżeniu 0,2%. To niewiele, znacznie mniej niż w przypadku FAT32 czy NTFS, ale zostało osiągnięte kosztem dużych rozmiarów jednostki alokacji i nieekonomicznego wykorzystania dysku.
Liczba sektorów na ścieżkę (20 00), 20h lub 32 oraz liczba głowic (40 00), 40h lub 64. Wartości te określają wirtualną geometrię dysku używaną przez system plików do znajdowania jednostek alokacji.
Liczba sektorów ukrytych (20 00 00 00). W zapisie szesnastkowym 20h, w zapisie dziesiętnym 32. Jest to liczba sektorów pomiędzy fizycznym początkiem dysku a początkiem partycji. System operacyjny wykorzystuje ten obszar do zapisywania dodatkowych danych dotyczących dysku. Liczba 32 wskazuje, że jest to pierwsza partycja na dysku.
Całkowita liczba sektorów (E0 1F 03 00). W zapisie szesnastkowym 31FE0h, w zapisie dziesiętnym 204768 sektorów, co przy rozmiarze sektora równym 512 bajtów daje około 102 MB. Rozmiar partycji wyświetlany przez konsolę Zarządzanie Dyskami (Disk Management console) jest tylko przybliżeniem. W systemie Windows 2000 partycja FAT16 może być sformatowana z jednostkami alokacji o rozmiarze 64 kB, więc maksymalny rozmiar partycji wynosi 4 GB. Rozmiar partycji instalacyjnej Windows NT został ograniczony do 2 GB, ponieważ sterownik FAT znajdujący się na dyskach instalacyjnych może odczytywać dane z jednostek alokacji o maksymalnym rozmiarze 32 kB. Jeśli rozmiar partycji instalacyjnej Windows 2000 przekracza 2 GB, to system automatycznie formatuje ją z wykorzystaniem systemu plików FAT32.
Numer dysku (Drive Type) (80). W zapisie szesnastkowym 80h (nie stosuje się postaci dziesiętnej). Z punktu widzenia systemu operacyjnego dyski numerowane są kolejno, rozpoczynając od 80h (pierwszy dysk), drugi dysk ma numer 81h itd. Ta pozycja w BPB prawie zawsze jest równa 80h niezależnie od rzeczywistego położenia dysku.
Pozycja specjalna (00). Dwa najmłodsze bity są wykorzystywane jako flagi. Bit zerowy jest nazywany flagą błędu (dirty flag) i jest ustawiany w wypadku nieprawidłowego zamknięcia systemu. Ustawienie tej flagi powoduje uruchomienie przez Windows 2000 wersji rozruchowej programu Chkdsk nazwanej Autochk. Następny bit jest bitem diagnostyki i powoduje, że system w trakcie rozruchu sprawdza poprawność plików i katalogów oraz skanowanie powierzchni dysku. Ten bit jest zwykle ustawiany razem ze znacznikiem błędu.
Sygnatura dysku (Disk signature) (29). W zapisie szesnastkowym 29h (nie stosuje się postaci dziesiętnej). Wartość taka oznacza obecność Extended BPB. Windows 2000 rozpoznaje wartości 28h lub 29h.
Numer seryjny woluminu (Serial number of the volume) (20 24 ED 64). W zapisie szesnastkowym 64ED-2420 (nie stosuje się postaci dziesiętnej). Numer ten pozwala na jednoznaczną identyfikację woluminu. Nie należy mylić tego numeru z --> unikalnym[Author:UP] identyfikatorem globalnym (Globally Unique Identifier) wykorzystywanym przez LDM. Informacje o partycjach sprzętowych są zapisane w innym miejscu.
Etykieta woluminu (Legacy volume label) (4E 4F 20 4E 41 4D 45 20 20 20 20). Partycja FAT16 zawsze nosi etykietę NO NAME uzupełnioną spacjami do 11 znaków. Rzeczywista etykieta jest zapisana na pierwszej pozycji głównego katalogu systemowego (root directory).
Deskryptor systemu plików (File system descriptor) (46 41 54 31 36 20 20 20). Zawiera nazwę zastosowanego systemu plików. Partycje sformatowane przez Windows 2000 mogą mieć jedną z następujących nazw: FAT12, FAT16, FAT32 lub NTFS. Partycja FAT12 jest mniejsza niż 32 MB i wykorzystuje 12-bitową tablicę FAT.

BPB dla systemu plików FAT32

Pierwszą cechą danych dotyczących systemu plików FAT32, zapisanych w sektorze rozruchowym, na którą zwraca się uwagę, jest to, że zajmują więcej miejsca niż dla FAT16. Dzieje się tak dzięki nowym właściwościom systemu plików FAT32, wymagającym większego obszaru do zaimplementowania. Oficjalna nazwa takiej powiększonej struktury brzmi Big FAT BIOS Parameter Block.

Sektor Big FAT BOOT FS Info znajduje się bezpośrednio za sektorem rozruchowym i zawiera specjalne informacje ułatwiające systemowi plików wyszukiwanie wolnych jednostek alokacji. Poniżej zamieszczono wydruk BPB i BFBPB zawierający również pierwsze 11 bajtów sektora rozruchowego.

EB 58 90 4D 53 44 4F 53 35 2E 30 00 02 02 20 00 .<.MSDOS5.0... .

02 00 00 00 00 F8 00 00 20 00 40 00 20 00 00 00 ...... . .@. ...

E0 1F 03 00 1A 03 00 00 00 00 00 00 02 00 00 00 ................

01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

80 00 29 D9 F7 56 DC 4E 4F 20 4E 41 4D 45 20 20 ..)..V. NO NAME

20 20 46 41 54 33 32 20 20 20 33 C9 8E D1 BC F4 FAT32 3..

Liczba bajtów w sektorze (00 02). W zapisie szesnastkowym 200h,w zapisie dziesiętnym 512. Większość dysków ma sektory 512-bajtowe.
Liczba sektorów w jednostce alokacji (02). Stanowi połowę liczby sektorów w jednostce alokacji systemu plików FAT16, ale nadal jest to więcej od oczekiwanej wartości jednego sektora w jednostce alokacji. Wyjaśnienie tego faktu nastąpi później.
Liczba sektorów rezerwowych poprzedzających tablicę alokacji plików FAT (20 00). W zapisie szesnastkowym 0020h, w zapisie dziesiętnym 32. Tyle sektorów znajduje się teraz pomiędzy sektorem rozruchowym a pierwszą tablicą FAT. Jest to jedno z ulepszeń systemu plików FAT32 w stosunku do FAT16. Tablica FAT nie musi znajdować się w ściśle określonym położeniu. Dodatkowe miejsce pozwala systemowi plików zapisywać informacje pomiędzy sektorem rozruchowym i swoim sektorem początkowym. Są to opisane poniżej File Information Sector oraz Boot Sector Copy.
Liczba kopii tablicy FAT (02). W systemie plików FAT32 również jest tworzona kopia tablicy FAT, przy czym w Windows 9x jest to opcja, natomiast w Windows 2000 nie ma możliwości pominięcia wykonania takiej kopii.
Maksymalna liczba pozycji w głównym katalogu systemowym (Maximum Entries in Root Directory) (00 00). Katalog ten w systemie plików FAT32 został uwolniony od ograniczenia liczby plików do 512, które występowało w systemie plików FAT16 i teraz może zawierać do 65532 plików i katalogów. FAT32 pozwala także na stosowanie długich nazw plików z dodatkowymi pozycjami w katalogu, co zwiększa liczbę odwołań do plików (handle), rozszerzając możliwości stosowania takich nazw.
Liczba małych sektorów (Small Sectors) (00 00). Ta pozycja jest zawsze równa 0, ponieważ w Windows 2000 nie da się sformatować partycji FAT32 z liczbą jednostek alokacji poniżej 65526.
Deskryptor nośnika (Media Descriptor) (F8). Ta pozycja jest zawsze równa F8. W systemie Windows 2000 tylko twarde dyski mogą być sformatowane w systemie plików FAT32, dyskietki formatuje się nadal w systemie FAT.
Liczba sektorów zajętych przez tablicę FAT (00 00). Ta pozycja pochodzi z systemu plików FAT i nie ma zastosowania w omawianym systemie plików. Ustawienie wartości na 0 jest traktowane przez system operacyjny jako znacznik systemu FAT32.
Liczba sektorów na ścieżkę (20 00), 20h (dziesiętnie 32) oraz liczba głowic (40 00), 40h (dziesiętnie 64). Wartości te są takie same, jak ich odpowiedniki w systemie plików FAT16, ponieważ obydwa systemy plików rozpoznają taką samą budowę dysku logicznego.
Liczba sektorów ukrytych (20 00 00 00). W zapisie szesnastkowym 20h, w zapisie dziesiętnym 32. Znaczenie takie, jak w przypadku FAT16 — liczba sektorów pomiędzy fizycznym początkiem partycji a sektorem rozruchowym.
Całkowita liczba sektorów (E0 1F 03 00). W zapisie szesnastkowym 31FE0h, w zapisie dziesiętnym 204768. Znaczenie takie samo, jak w przypadku FAT16.
Liczba sektorów zajętych przez tablicę FAT (1A 03 00 00). W zapisie szesnastkowym 31Ah, w zapisie dziesiętnym 794. To nowa pozycja. Zysk w stosunku do systemu plików FAT16 osiągnięto z dwóch powodów; pierwszy to taki, że liczbę sektorów zapisuje się teraz na czterech bajtach zamiast na dwóch, drugi — że wolumin zawiera więcej jednostek alokacji. Razem z kopią tablicy FAT system plików zajmuje 794 kB z woluminu 100 MB, czyli stosunek obszaru zajętego przez system plików do całkowitego obszaru woluminu wynosi w przybliżeniu 0,8%. Jest to 4 razy więcej, niż w przypadku FAT16, ale i tak niewiele w porównaniu z systemem plików NTFS.
Flagi (00 00). Nowa pozycja, mogąca przyjmować dwie wartości. Ustawienie najstarszego bitu powoduje utworzenie lustrzanej kopii pierwotnej tablicy FAT. Wtedy na czterech najmłodszych bitach zapisana jest liczba kopii. Windows 2000 wykonuje tylko jedną kopię tablicy FAT.
Wersja systemu plików (00 00). Nowa pozycja wykorzystywana tylko przez Windows 9x. Starszy bajt określa wersję, a młodszy — wersję narastającą. Dla Windows 2000 obydwa bajty mają wartość 0.
Jednostka alokacji głównego katalogu systemowego (Root Cluster) (02 00 00 00). W zapisie szesnastkowym 02h. Nowa pozycja. Podaje numer jednostki alokacji głównego katalogu systemowego (root directory) w tablicy FAT, co pozwala na umieszczenie tego katalogu w dowolnym miejscu partycji.
Sektor informacji systemu plików (File System Information Sector) (01 00). W zapisie szesnastkowym 01h. Nowa pozycja. Wskazuje na sektor zawierający całkowicie wolne jednostki alokacji i numer ostatnio przydzielonej jednostki, pozwalając systemowi plików podawać te wartości bez przeszukiwania całej tablicy FAT. Zazwyczaj sektor ten jest umiejscowiony zaraz za sektorem rozruchowym w sektorach rezerwowych.
Zapasowy sektor rozruchowy (Backup Boot Sector) (06 00). 06h. Nowa pozycja. Określa położenie względne zapasowego sektora rozruchowego, który usuwa jeszcze jedną słabość systemu plików FAT16. W przypadku uszkodzenia sektora rozruchowego, system może odczytać informacje o konfiguracji z jego kopii umieszczonej w obszarze sektorów rezerwowych zaraz za pierwotnym sektorem rozruchowym.
Bajty rezerwowe (00 00 00 00 00 00 00 00 00 00 00 00). Pozostawione do wykorzystania w przyszłości.
Numer dysku (Drive Type) (80). Patrz opis dla FAT16.
Pozycja specjalna (00). Patrz opis dla FAT16.
Sygnatura (29). Patrz opis dla FAT16.
Numer seryjny woluminu (DA 2F BB 58). Patrz opis dla FAT16.
Etykieta woluminu (4E 4F 20 4E 41 4D 45 20 20 20 20). Patrz opis dla FAT16. Końcowe spacje są częścią nazwy.
System plików (46 41 54 33 32 20 20 20). Nazwa systemu plików zapisana przez Windows 2000 jako FAT32. Końcowe spacje są częścią nazwy.

BPB systemu plików NTFS

System plików NTFS nie potrzebuje wielu danych z sektora rozruchowego. Poniżej zamieszczono wydruk 61 bajtów tworzących BPB i Extended BPB wraz z pierwszymi 11 bajtami sektora rozruchowego.

<<BPB i rozszerzony BPB dla partycji NTFS. Zamieszczono pierwsze 11 bajtów sektora rozruchowego.>>

EB 52 90 4E 54 46 53 20 20 20 20 00 02 01 00 00 .R.NTFS .....

00 00 00 00 00 F8 00 00 20 00 40 00 20 00 00 00 ........ .@. ...

00 00 00 00 80 00 80 00 DF 1F 03 00 00 00 00 00 ................

56 06 00 00 00 00 00 00 D6 30 02 00 00 00 00 00 V........0......

02 00 00 00 08 00 00 00

Liczba bajtów w sektorze (00 02). W zapisie szesnastkowym 200h, w zapisie dziesiętnym 512. Większość dysków ma sektory 512-bajtowe.
Liczba sektorów w jednostce alokacji (01). Dla NTFS rozmiar jednostki alokacji wynosi jeden sektor dopóty, dopóki wolumin nie jest zbyt duży, około 500 MB, przy czym rozmiar jednostki alokacji podwaja się wraz z dwukrotnym wzrostem rozmiaru woluminu. Na przykład dla woluminu o wielkości 1 GB domyślny rozmiar jednostki alokacji wynosi 2 kB, dla woluminu 2 GB rozmiar ten równy jest 4 kB itd. Największy rozmiar jednostki alokacji dla systemu plików NTFS wynosi 64 kB. Jest to wartość domyślna dla woluminów o wielkości powyżej 32 GB. W porównaniu z systemami plików FAT32, NTFS umożliwia stosowanie woluminów czterokrotnie większych, przy tej samej wielkości jednostki alokacji.
Liczba sektorów rezerwowych (00 00). System NTFS umieszcza sektor rozruchowy dokładnie na początku partycji.
Liczba kopii tablicy FAT (00). Niewykorzystywane.
Maksymalna liczba pozycji w głównym katalogu systemowym (Maximum Entries in Root Directory) (00 00). Niewykorzystywane.
Liczba małych sektorów (Small Sectors) (00 00). Niewykorzystywane.
Deskryptor nośnika (Media Descriptor) (F8). Ta pozycja jest zawsze równa F8 i oznacza dysk twardy, tak samo jak w przypadku systemu plików FAT.
Liczba sektorów zajętych przez tablicę FAT (00 00). Niewykorzystywane.
Liczba sektorów na ścieżkę (20 00), 20h (dziesiętnie 32) oraz liczba głowic (40 00), 40h (dziesiętnie 64). Wartości te są takie same, jak ich odpowiedniki w systemach plików FAT16 i FAT32.
Liczba sektorów ukrytych (20 00 00 00). W zapisie szesnastkowym 20h, w zapisie dziesiętnym 32. Znaczenie takie, jak w przypadku systemów FAT16 i FAT32.
Całkowita liczba sektorów (00 00 00 00). Niewykorzystywane. Pozycja ta to pozostałość po starszych systemach plików i jest zbyt mała dla przestrzeni adresowej NTFS. Poniżej znajduje się jeszcze jedna pozycja o identycznej nazwie, ale dostosowana do adresowania 64-bitowego.
Liczba sektorów zajętych przez tablicę FAT (80 00 80 00). Niewykorzystywane.
Całkowita liczba sektorów (DF 1F 03 00 00 00 00 00). Nowa pozycja. Podwójne słowo wystarcza do zaadresowania 2⁶⁴ sektorów, chociaż ograniczeniem praktycznym jest liczba 2³² sektorów, czyli 2 TB. Obecnie wydaje się, że 2 TB to dużo, ale poczekajmy na wersję beta pakietu Office 2002.
Numer logicznej jednostki alokacji tablicy MFT (56 06 00 00 00 00 00 00). W zapisie szesnastkowym 656h, w postaci dziesiętnej 1622. Do wyszukiwania plików NTFS, podobnie jak FAT i FAT32, używa jednostek alokacji, a nie sektorów. Każda jednostka alokacji ma swój numer tzw. Logical Cluster Number (LCN). W tym przykładzie MFT tego woluminu zaczyna się w jednostce alokacji o numerze 1622. Zazwyczaj MFT znajduje się jak najbliżej początku woluminu, aby uzyskać lepszą przepustowość danych, wykorzystując większą prędkość dysku. Wartość LCN w powyższym przykładzie wskazuje, że dla danej partycji wykonano konwersję systemu plików z FAT32 na NTFS, a na początku dysku nie było wolnego obszaru o odpowiedniej wielkości dla MFT.
Numer logicznej jednostki alokacji kopii tablicy MFT (FF 8F 01 00 00 00 00 00). 018FFFh. System plików umieszcza kopię MFT blisko środka partycji. Jeśli system nie jest w stanie odczytać pierwotnego rekordu $MFT zawierającego lokalizację innych rekordów MFT, sięga do BPB w poszukiwaniu kopii, wpisując również do dziennika zdarzeń (Event Log) komunikat o wystąpieniu błędu.
Liczba jednostek alokacji w rekordzie MFT (02 00 00 00). W powyższym przykładzie liczba jednostek alokacji w rekordzie wynosi 2, co daje wielkość rekordu MFT równą 1024 bajty. Jest to domyślna wartość wielkości rekordu dla Windows 2000 i NT4. We wcześniejszych wersjach NT wielkość rekordu wynosiła 2 kB i 4 kB. Im większy rekord, tym lepsze wykorzystanie dysku przy zapisywaniu małych plików, ponieważ informacje o pliku mieszczą się w jego rekordzie MFT. To były piękne dni, kiedy aplikacje tworzyły niewielkie pliki. Obecnie 4 kB ledwie wystarczą do zapisania nagłówka pliku. W Microsofcie przemyślano jeszcze raz strategię dotyczącą MFT i opowiedziano się za niewielkimi rozmiarami rekordu.
Wielkość indeksu MFT (Liczba jednostek alokacji) (08 00 00 00). Indeks MFT jest to tablica binarna pokazująca układ tablicy MFT. Informacja ta zapisana jest w rekordzie metadanych MFT o nazwie $Bitmap.
Numer seryjny woluminu (C2 8D 68 AC CB 68 AC F0). Patrz opis dla FAT16.
Suma kontrolna (00 00 00 00). 32-bitowa suma kontrolna tablicy MFT stosowana aby sprawdzić, czy tablica jest wolna od błędów.

Główną przewagą systemu plików NTFS nad systemami FAT i FAT32 jest efektywne wykorzystanie dysku poprzez używanie jednostek alokacji o niewielkich rozmiarach w stosunku do wielkości woluminu. Dokonując tylko konwersji systemu plików z FAT na NTFS można odzyskać setki megabajtów dysku twardego. W tablicy 13.1 pokazano wartości domyślne rozmiarów jednostki alokacji dla danych wielkości woluminu.

Tablica 13.1. Rozmiary jednostki alokacji NTFS jako funkcja wielkości woluminu

Wielkość woluminu	Rozmiar jednostki alokacji
<=512 MB	512 bajtów
513 MB - 1 GB	1 kB
1 GB - 2 GB	2 kB
2 GB - 4 GB	4 kB
4 GB - 8 GB	8 kB
8 GB - 16 GB	16 kB
16 GB - 32 GB	32 kB
>32 GB	64 kB

Można zastanawiać się, dlaczego NTFS potrzebuje jednostek alokacji o rozmiarze większym niż jeden sektor i tak wiele adresów na swoje potrzeby. Jest to związane z wydajnością. Na przykład weźmy pod uwagę wolumin o rozmiarze 32 GB. Gdyby wolumin ten był sformatowany w ten sposób, że jeden sektor równałby się jednej jednostce alokacji, system plików musiałby śledzić zawartość 64 miliardów jednostek alokacji. Ogrom obliczeń z tym związanych znacznie spowolniłby pracę komputera i spowodowałby rozrost bazy danych systemowych do monstrualnych rozmiarów. Wartości domyślne rozmiarów jednostki alokacji są wynikiem kompromisu pomiędzy wydajnością, a efektywnym wykorzystaniem dysku.

Jak już powiedziano, te rozmiary jednostki alokacji systemu NTFS wprowadzono kilka lat temu. Nowoczesny serwer z dyskami SCSI lub fast ATA, specjalnym sterownikiem dysku (tzw. bus-mastering disk interface card) oraz szybkimi procesorami radzi sobie z rozmiarami jednostki alokacji mniejszymi o stopień lub dwa niż wartości domyślne.

Na przykład można sformatować wolumin 32 GB stosując 32- lub 16-kilobajtowe jednostki alokacji bez obniżenia wydajności. Odpowiedni rozmiar jednostki alokacji wybiera się poprzez konsolę Zarządzanie Dyskiem lub używając odpowiedniej opcji polecenia Format. Przykładowo, aby sformatować wolumin w systemie NTFS z 16-kilobajtową jednostką alokacji należy użyć tego polecenia w postaci format d: /fs:ntfs /a:16k.

W celu zmiany rozmiaru jednostki alokacji należy ponownie sformatować wolumin. Nie ma ograniczenia rozmiaru jednostki alokacji woluminu NTFS zawierającego pliki rozruchowe lub systemowe Windows 2000. Podczas konwersji na NTFS domyślny rozmiar jednostki alokacji jest ustalony na 1 sektor, czyli 512 bajtów i nie może być zmieniony.

Do kompresji konieczne jest stosowanie niewielkich jednostek alokacji.

Nie można wykonać kompresji plików NTFS, jeśli jednostka alokacji jest większa niż 4 kB, więc dysk o dużej pojemności, który ma być poddany kompresji, uprzednio musi być odpowiednio sformatowany. Małe jednostki alokacji na dużym woluminie w połączeniu z powolnością kompresji NTFS mogą być przyczyną znaczącego obniżenia wydajności.

Wielkość jednostki alokacji jest ustalana na podstawie rozmiaru woluminu, a nie pojemności dysku. Jeśli utworzymy duży wolumin NTFS na macierzy dyskowej RAID, to domyślny rozmiar jednostki alokacji będzie odpowiadał logicznemu rozmiarowi woluminu.

Podsumowanie

Poniżej podano najważniejsze informacje o budowie sektora rozruchowego dla trzech systemów plików:

Lokalizacja tablicy FAT w systemie plików FAT jest niezmienna. Jeśli dojdzie do uszkodzenia sektora zawierającego tę tablicę, system nie nadaje się do użytku.W systemie plików FAT32 lokalizacja tablicy FAT nie jest stała.
Tablica plików posiada kopię zarówno dla woluminów FAT jak i FAT32.
Liczba plików w głównym katalogu partycji FAT jest ograniczona do 512. Maksymalna liczba plików partycji FAT32 wynosi 65532.
W systemach plików FAT i FAT32 można używać długich nazw plików wykorzystując dodatkowe pozycje folderu.
Ograniczona przestrzeń adresowa systemu plików FAT16 prowadzi do marnowania obszaru dysku z powodu dużych rozmiarów jednostek alokacji. Woluminy FAT32 mają mniejsze jednostki alokacji a NTFS najmniejsze.
FAT32 wykorzystuje wartości 4-bajtowe, które nie są kompatybilne z narzędziami dyskowymi starej wersji DOS.
Tablica plików systemu FAT32 jest dużo większa niż FAT16, a trzeba jeszcze wziąć pod uwagę jej kopię. Windows 2000 wprowadza ograniczenia na pojemność woluminu FAT32 do wartości 32 GB po to, by cała tablica plików mieściła się w pamięci podręcznej.
Sektor informacji o systemie plików (File System Information) dla FAT32 przyspiesza przydzielanie jednostek alokacji.
Systemy plików FAT32 oraz NTFS wykonują kopie sektora rozruchowego, aby zwiększyć odporność na błędy.
NTFS wykorzystuje Master File Table (MFT) do zapisywania rekordów pliku.
Można dokonać konwersji woluminów FAT i FAT32 do systemu plików NTFS, ale konwersja odwrotna nie jest możliwa.
Położenie MFT w woluminie NTFS nie jest ustalone. Częściowa kopia MFT jest zapisana w środku dysku w celu zwiększenia odporności na błędy.
NTFS wytrzymuje utratę sektora zawierającego rekordy MFT.

Struktura tablic FAT i MFT

Przeznaczeniem systemu plików jest śledzenie plików. DOS wprowadził tablicę alokacji plików (File Allocation Table - FAT), która określa strukturę plików i ich rozmieszczenie w woluminie. Tablica FAT jest zasadniczo mapą pokazującą, które jednostki alokacji są w użyciu, a które nie. Pliki powiązane z każdym elementem tablicy są indeksowane w rekordach katalogu. W Windows 9x OSR2 rozszerzono tablicę FAT,co umożliwiło adresowanie 32-bitowe, ale pozostawiając jej podstawową funkcję odwzorowywania jednostki alokacji i indeksowania katalogu.

NTFS prezentuje całkowicie odmienne rozwiązanie, oparte na hierarchicznej bazie danych, tzw. główną tablicę plików (Master File Table - MFT). Pliki i foldery są reprezentowane w MFT przez rekordy zawierające atrybuty, które opisują ich zawartość. Ponieważ MFT jest raczej bazą danych, a nie prostą mapą jednostki alokacji, zapisane w niej jest więcej informacji niż w tablicy FAT i może być indeksowana na więcej sposobów niż tylko według nazwy pliku. Poniżej zawarto opis funkcjonalny tablicy FAT i MFT. MFT jest opisany bardziej szczegółowo w dalszej części niniejszego rozdziału.

Odwzorowanie jednostki alokacji systemu plików FAT

System plików FAT16 wykorzystuje 16-bitowe adresowanie jednostek alokacji. W systemie plików FAT32 zastosowano adresowanie 32-bitowe. Poniżej przedstawiono wydruk standardowej tablicy FAT.

<<Tablica systemu FAT16 dla 23 plików. Pogrubioną czcionką pokazano plik zajmujący 12 jednostek alokacji.>>

F8FF FFFF FFFF FFFF FFFF FFFF FFFF FFFF

0900 FFFF 0B00 FFFF 0D00 FFFF 0F00 FFFF

1100 1200 1300 FFFF FFFF FFFF FFFF FFFF

FFFF FFFF FFFF FFFF FFFF FFFF 1F00 2000

2100 2200 2300 FFFF 2500 2600 2700 2800

2900 2A00 2B00 2C00 2D00 2E00 2F00 FFFF

Pierwszy bajt tablicy FAT, F8h, oznacza rodzaj medium. Trzy następne bajty są rezerwowe. W kolejnych 2 bajtach zapisany jest numer jednostki alokacji lub jedna z poniższych wartości:

FFFF. Koniec pliku.
FFF7. Uszkodzona jednostka alokacji.
FFF5. Rezerwowa jednostka alokacji.

Dalsze wartości FFFF oznaczają, że plik lub katalog mieszczą się w jednej jednostce alokacji. Pliki rozmieszczone w kilku jednostkach można rozpoznać po tym, że w tych pozycjach mają wpisane ich numery kolejne. Pozycje zaznaczone na wydruku pogrubioną czcionką pokazują, że plik zaczyna się w jednostce alokacji o numerze 0025 (należy pamiętać o kolejności bajtów), a kończy w jednostce o numerze 3000 (wskazuje na to znacznik końca pliku FFFF). Na tej podstawie nie można określić dokładnego rozmiaru pliku, wiadomo tylko, że zajmuje 12 jednostek alokacji. Gdyby rozmiar jednostki alokacji wynosił 32 kB, plik zajmowałby 394 kB.

Kopia tablicy FAT znajduje się zaraz za oryginałem. W razie uszkodzenia sektora pierwotnej tablicy FAT, przez co nie można odczytać danych z jednostki alokacji, system korzysta z kopii.

Zaletą systemu plików FAT są niewielkie rozmiary tablicy FAT i szybkość działania. Właściwie ta tablica nie jest niczym więcej niż rodzajem cyfrowego planu dysku, pokazującym położenie i rozmiar każdego z plików. Przeszukiwanie jest błyskawiczne, jeśli jej wielkość jest mała w porównaniu z rozmiarami dysku. Dla woluminu 1 GB z 32-kilobajtowymi jednostkami alokacji tablica FAT ma trochę powyżej 32000 pozycji, każda pozycja zajmuje 2 bajty, z czego wynika, że tablica FAT zajmuje obszar 64 kB.

Odwzorowanie jednostki alokacji systemu plików FAT32

Układ mapy jednostki alokacji FAT32 jest taki sam jak FAT16, z tą różnicą, że każdy element zapisany jest na 4 bajtach (32 bity, a nie na 2 bajtach (16 bitów). Oto przykładowy wydruk tablicy FAT32:

<<Tablica FAT32 dla 16 plików.>>

F8FFFFFF FFFFFFFF FFFFFF0F FFFFFF0F

FFFFFF0F FFFFFF0F FFFFFF0F FFFFFF0F

09000000 0A000000 0B000000 FFFFFF0F

FFFFFF0F 0E000000 FFFFFF0F FFFFFF0F

FFFFFF0F FFFFFF0F FFFFFF0F FFFFFF0F

15000000 16000000 17000000 FFFFFF0F

19000000 1A000000 1B000000 1C000000

1D000000 1E000000 1F000000 20000000

21000000 22000000 23000000 24000000

25000000 26000000 27000000 FFFFFF0F

Pierwszy bajt, F8h, określa rodzaj medium, następne 7 bajtów to rezerwa. Kolejne pozycje, składające się z podwójnych słów (każde czterobajtowe) reprezentują jednostki alokacji. Ciąg znaków FFFFFF0F jest znacznikiem końca pliku.

Powiększona przestrzeń adresowa w systemie plików FAT32 pozwala na stosowanie naprawdę ogromnych woluminów, ale w dalszym ciągu konieczne są stosunkowo duże jednostki alokacji, aby tablica FAT nie rozrosła się za bardzo. Na przykład weźmy pod uwagę dysk 8 GB, niezbyt wielki, jak na dzisiejsze standardy. Gdyby został sformatowany jako jeden wolumin FAT32 z jednostką alokacji zajmującą 2 sektory, tablica FAT zawierałaby 8 milionów elementów po 4 bajty każdy. Dodajmy do tego kopię tablicy FAT, nieobowiązkową dla Windows 9x, ale wymaganą przez Windows 2000, a w wyniku otrzymamy wielkość obszaru zajętego przez system plików wynoszącą 64 MB. Do tego dochodzą jeszcze sektory zajęte przez katalogi.

Aby przyspieszyć przeszukiwanie tablicy FAT, system operacyjny stara się trzymać ją całą w pamięci operacyjnej, ale w sytuacji opisanej powyżej jest to nieosiągalne. Nie tylko przeszukiwanie takiej struktury o monstrualnych rozmiarach jest czasochłonne, ale również prawdopodobieństwo błędu graniczy z pewnością, szczególnie w przypadku fragmentacji dysku.

Katalogi wykorzystywane jako indeksy tablicy FAT

Zarówno system plików FAT, jak i FAT32 wykorzystują katalogi do indeksowania odwzorowania jednostek alokacji zapisanych w tablicy FAT. Rekord katalogu przechowuje nazwy plików i katalogów mieszczących się w danym katalogu. Katalog taki może być zapisany w dowolnym miejscu dysku, mając przyporządkowaną jednostkę alokacji tak jak plik, ponieważ dla systemu plików są one nierozróżnialne. Poniżej przedstawiony jest wydruk dla katalogu z woluminu FAT16.

<<Główny katalog systemowy woluminu FAT16. Pogrubioną czcionką zaznaczono numer początkowej jednostki alokacji w tablicy FAT.>>

4E 45 57 20 56 4F 4C 55 4D 45 20 08 00 00 00 00 NEW VOLUME .....

00 00 00 00 00 00 45 A4 CE 26 00 00 00 00 00 00 ......E..&......

4F 4E 45 20 20 20 20 20 54 58 54 10 08 79 BD A4 ONE TXT..y..

CE 26 CE 26 00 00 C0 A4 CE 26 02 00 00 00 00 00 .&.&.....&......

54 57 4F 20 20 20 20 20 54 58 54 10 08 BB C0 A4 TWO TXT.....

CE 26 CE 26 00 00 C1 A4 CE 26 08 00 00 00 00 00 .&.&.....&......

E5 48 52 45 45 20 20 20 54 58 54 10 08 A2 C1 A4 .HREE TXT.....

CE 26 CE 26 00 00 C2 A4 CE 26 12 00 00 00 00 00 .&.&.....&......

Każdy element odpowiada jakiemuś plikowi lub podkatalogowi i zawiera numer jednostki alokacji tego pliku lub katalogu zapisany w tablicy FAT (pogrubiona czcionka). Katalog z powyższego wydruku to główny katalog systemowy (Root directory), stąd pierwsza pozycja jest nazwą woluminu. W przypadku zwyczajnego katalogu pierwszymi dwiema pozycjami byłyby (.) oraz (..), co oznacza tenże katalog i jego katalog nadrzędny.

Dolna część wydruku rozpoczynająca się od .HREE TXT, dotyczy pliku skasowanego. Jak powszechnie wiadomo, system plików FAT w rzeczywistości nie wymazuje danych z dysku, zamienia tylko pierwszą literę nazwy pliku na znak σ o kodzie ASCII 229 (E5h). Programy odtwarzające plik przywracają jego pełną nazwę oraz przeszukują dysk, aby określić czy można ponownie ustanowić połączenia pomiędzy danymi, zapisanymi w tablicy FAT, dotyczącymi tego pliku.

Układ wydruku katalogu w systemach plików FAT/FAT32

Poniższy wyciąg z wydruku katalogu zawiera dane dla pojedynczego pliku. Należy pamiętać o zmianie kolejności bajtów w słowach i podwójnych słowach danych.

<<Fragment katalogu dotyczący pliku.>>

54 57 4F 20 20 20 20 20 54 58 54 10 08 BB C0 A4 TWO TXT.....

CE 26 CE 26 00 00 C1 A4 CE 26 08 00 00 00 00 00 .&.&.....&......

Nazwa (54 57 4F 20 20 20 20 20 54 58 54). Pierwsze 11 bajtów zajmuje nazwa pliku, w tym przykładzie jest to TWO TXT. Nazwa pliku jest uzupełniona spacjami do 8 bajtów, a rozszerzenie do trzech. Długie nazwy plików są obsługiwane przez Windows 2000 i NT poprzez dopisanie pozycji w katalogu, które przechowują dodatkowe znaki nazwy.
Atrybut (10). Pozycja ta zawiera bity określające wartość atrybutów pliku: tylko do odczytu, ukryty, systemowy i archiwalny, jak w systemie operacyjnym DOS.
Rezerwa (08 BB C0 A4 CE 26 CE 26 00 00). Obszar dziesięciu bitów rezerwowych.
Znacznik daty i czasu (C1 A4 CE 26). Cztery bajty przedstawiające datę i czas utworzenia pliku.
Pozycja w tablicy FAT (08 00). W zapisie szesnastkowym 08h. Dwa bajty odpowiadające numerowi jednostki alokacji w tablicy FAT. Wartość przykładowa, 08h, oznacza, że początek pliku znajduje się w ósmej jednostce alokacji. Katalog w systemie plików FAT32 wygląda tak samo, ale dostosowując się do większych rozmiarów tablicy FAT, stosuje 32 bity (typ long integer). Wykorzystuje się w tym celu jeden z bajtów rezerwowych.
Długość pliku (FE 0F 00 00). W zapisie szesnastkowym FFEh, lub w zapisie dziesiętnym 4094,bajty. Zawiera długość pliku wyrażoną w bajtach. System plików porównuje tę wartość z ciągiem jednostek alokacji w tablicy FAT, aby sprawdzić, czy nie ma błędów. Jeśli z tablicy FAT wynika, że długość równa jest dwom jednostkom alokacji, a wartość w polu Długość pliku odpowiada czterem jednostkom, to oznacza, że pojawił się problem.

Taka metoda opisywania plików ma wady w przypadku dużych woluminów. System plików musi najpierw znaleźć nazwę pliku w swoim rekordzie katalogu. Katalogi są rozproszone, więc może być konieczne przeszukiwanie całego dysku. Kiedy już rekord katalogu zostanie znaleziony, jedyną użyteczną informacją dotyczącą pliku jest numer kolejny jednostki alokacji z tablicy FAT. Teraz głowice dysku powracają na początek woluminu, aby odczytać z tej tablicy (lub jej kopii umieszczonej w pamięci podręcznej) pozostałe numery jednostek alokacji. Dopiero teraz głowice dysku przenoszą się na początek pliku.

Proces przeszukiwania dysku jest jeszcze bardziej pracochłonny w przypadku dużego stopnia jego fragmentacji. Pozycje katalogu mają długość równą 32 bajty, ale katalog jako taki zajmuje całą jednostkę alokacji, co podkreśla marnotrawstwo dysku o dużej pojemności, na którym zapisano wiele katalogów i podkatalogów. Jeśli jednostka alokacji jest zapełniona i nie ma sąsiedniej, aby zapisać pozostałe dane, może również dojść do fragmentacji katalogu.

Budowa rekordu pliku w systemach plików FAT/FAT32

Najmniej interesującą częścią systemu plików FAT jest rekord pliku. Na zakończenie opisu tego systemu plików pokazano jeden przykładowy. Początek pliku umieszczony jest na granicy jednostki alokacji.

<<Początek jednostki alokacji zawierający plik.>>

7468 6973 2069 7320 6120 736D 616C 6C20 this is a small

6669 6C65 2E20 0000 0000 0000 0000 0000 file. .........

0000 0000 0000 0000 0000 0000 0000 0000 000000000000000

Jeśli rozmiar jednostki alokacji dla tego woluminu wynosi 32 sektory, to ten 22-bajtowy plik zużywa 16 kB, co świadczy o dość słabym stopniu wykorzystania dysku. Przy zastosowaniu systemu plików FAT32, dysk jest wykorzystany lepiej, dzięki większej przestrzeni adresowej pozwalającej na zmniejszenie rozmiarów jednostki alokacji.

Opis funkcjonalny MFT

W odróżnieniu od systemów plików FAT oraz FAT32, które lokalizują pliki na podstawie mapy jednostek alokacji, system NTFS wykorzystuje hierarchiczną obiektową bazę danych MFT. MFT składa się z rekordów o stałej długości 1 kB, zapisanych w postaci tablicy. W każdym rekordzie zapisany jest zestaw atrybutów, które wzięte razem, jednoznacznie identyfikują położenie i zawartość odpowiadających im plików lub katalogów. (Istnieją odstępstwa od zasady „jeden rekord, jeden plik”, pojawiają się tylko dla bardzo dużych plików o wysokim stopniu fragmentacji).

Rekordy MFT są również obiektami systemowymi Windows 2000, więc mają taką samą ochronę ze strony systemu zabezpieczeń (Executive Security) jak rekordy Active Directory, zawartość Rejestru oraz sprzęt wirtualny (virtual hardware devices).

Wyróżniamy trzy klasy rekordów MFT:

Rekordy plików. Przechowują informacje określane zwykle jako „dane”, takie jak pliki aplikacji, sterowniki pliki systemowe, pliki baz danych itd.
Rekordy katalogów. Służą do przechowywania i indeksowania nazw plików. Rekordy katalogów indeksują również inne atrybuty, takie jak dynamiczne wskaźniki lokalizacji danych (reparse points), deskryptory ochrony (security descriptors) i informacje o połączeniach (link tracking).
Rekordy hybrydowe. Zawierają atrybuty związane z obydwoma wymienionymi powyżej rodzajami rekordów. Wykorzystywane są przez usługi specjalne.

MFT zawiera informacje określające jej własną strukturę (self-referential database), zapisane w specjalnych rekordach tzw. rekordach metadanych (metadata records). Na potrzeby systemu plików NTFS4 przeznaczono 16 rekordów metadanych, choć w rzeczywistości wykorzystywane jest 11, a pozostałe stanowią rezerwę. NTFS5 zajmuje na swoje potrzeby 26 rekordów MFT dla metadanych, a wykorzystuje 15. Zainteresowanie budzi fakt, że nie wykorzystuje żadnego z 5 rekordów rezerwowych NTFS4.

NTFS5 Całkowicie ukrywa pliki metadanych

W systemie NT4 można było wywołać pliki metadanych poleceniem dir /a:h $filename.

NTFS5 zupełnie ukrywa metadane. Wiadomo jednak, że takie pliki są, ponieważ zajmują miejsce na dysku. Wielkość obszaru zajętego na potrzeby metadanych można zobaczyć uruchamiając Chkdsk:

635008 kilobajtów całkowitego obszaru dysku

535691 kilobajtów w 8206 plikach użytkownika

1894 kilobajtów w 592 indeksach

14176 kilobajtów zajętych przez system

83247 kilobajtów dostępnych na dysku

Jak widać, system plików NTFS zajmuje znaczną część niewielkiego woluminu. Jednakże w przypadku woluminów o pojemności 10 GB i więcej, przy takiej samej wielkości jednostki alokacji, procentowy udział obszaru zajętego przez pliki systemowe NTFS jest mniejszy niż dla systemu plików FAT32.

Rysunek 13.1.

Struktura rekordów MFT w postaci hierarchicznej.

Root directory - katalog główny

Overflow --> files[Author:UP] -

Place holder records -

Named Stream -

--> Brak rysunku[Author:E]

Na rys. 13.1 pokazano budowę rekordu metadanych, przedstawionego w postaci plików i katalogów. Rekordy metadanych MFT zaczynają się od znaku dolara, $. Kolejność i budowa tych rekordów jest ściśle przestrzegana, ponieważ program ładujący, Ntldr, pracuje w trybie rzeczywistym i nie poradziłby sobie z bardziej złożoną strukturą.

Ntldr znajduje MFT na podstawie danych zapisanych w sektorze startowym (boot sector), następnie ładuje kilka pierwszych rekordów metadanych, wykorzystuje je do znalezienia plików systemowych, a potem kontynuuje ładowanie systemu operacyjnego.

Rekordy metadanych MFT i ich funkcje

Poniżej zamieszczono krótkie omówienie rekordów metadanych MFT i ich funkcji. Szczegółowy opis zamieszczono w dalszej części rozdziału.

$MFT. Wszystko, co jest zapisane na dysku, włączając w to tablicę MFT, NTFS traktuje jako pliki. $MFT jest rekordem pliku tablicy MFT. Rekord MFT jest skrzyżowaniem rekordu pliku (file record) i rekordu katalogu (directory record). Część z danymi zawiera wskaźniki do samej tablicy MFT i fragmentów tablicy MFT. Rekord katalogu zawiera atrybut bitowy, pokazujący, które rekordy są wykorzystane, a które nie. Program ładujący znajduje rekord $MFT wykorzystując wskaźnik zapisany w sektorze startowym.
$MFTMirr. NTFS zapisuje kopię kilku pierwszych rekordów tablicy MFT w połowie woluminu. W razie uszkodzenia jednostki alokacji zawierającej pierwotny rekord $MFT, system znajduje pozostałą część tablicy MFT, korzystając z kopii. $MFTMirr jest standardowym rekordem pliku zawierającym wskaźnik lokalizacji pliku pierwotnego.
$LogFile. Ten rekord zawiera lokalizację plików, w których zapisany jest przebieg operacji wykonywanych przez NTFS. NTFS umożliwia zapisywanie na dysk z buforowaniem danych. Ten sposób poprawia wydajność, ale jeśli informacja zapisana na dysku nie odpowiada zapisom w tablicy MFT, może być przyczyną uszkodzenia systemu plików. NTFS jest zabezpieczony przed tym poprzez usługę Log File Service (LFS), zapisującą dane krytyczne dla tablicy MFT do pliku przed transferem na dysk. W razie awarii systemu, NTFS odtwarza spójność systemu plików stosując do tablicy MFT informacje zapisane w pliku. Pozwala to na ominięcie drobiazgowej, pełnej przebudowy systemu po nieprawidłowym zamknięciu systemu. Rekord $LogFile ma budowę standardowego rekordu pliku z atrybutem danych, który wskazuje na dwa pliki dziennika zdarzeń (log files), pierwotny i jego kopię, mieszczące się w środku woluminu.
$Volume. Ten rekord zawiera nazwę woluminu NTFS, jego rozmiar i wersję NTFS użytego do formatowania dysku twardego. $Volume jest zapisany w unikatowym formacie ze specjalnymi atrybutami.
$AttrDef. Ten rekord zawiera plik Attribute_Definition, w którym wymienione są atrybuty wykorzystywane przez system plików NTFS razem z informacjami o nich, takimi jak konieczność zapisania danego atrybutu w tablicy MFT lub możliwości przechowywania go gdziekolwiek na dysku. Rekord zapisany jest w standardowym formacie rekordu pliku.
$\. Ten rekord zawiera główny katalog systemowy (root directory) systemu plików. Tak samo jak w przypadku FAT i FAT32 katalogi są używane do indeksowania systemu plików według nazw plików. Główny katalog systemowy (root directory) jest rekordem metadanych, ponieważ jego położenie oraz zawartość mają podstawowe znaczenie dla znajdowania na dysku pozostałych danych. Rekord $\ zapisany jest w standardowym formacie rekordu katalogu.
$BitMap. Tak samo jak FAT i FAT32, NTFS utrzymuje odwzorowanie jednostek alokacji woluminu, co pozwala na określenie położenia niewykorzystanych jednostek alokacji. Jednakże odwzorowanie jednostek alokacji systemu plików NTFS wykorzystuje pojedyncze bity, więc nawet olbrzymie woluminy mogą być odwzorowane w postaci zwartej struktury. Rekord $BitMap zapisany jest w standardowym formacie rekordu pliku.
$Boot. Ten plik, zawierający lokalizację programu ładującego NTLDR, jest rekordem metadanych, ponieważ pierwotny program ładujący (primary bootstrap code) powinien znaleźć wtórny program ładujący (secondary bootstrap code). Nie może tego wykonać bez odwołania się do tablicy MFT. Plik NTLDR jest zazwyczaj umieszczony zaraz po sektorach rezerwowych następujących po sektorze startowym. Rekord $Boot jest zapisany w standardowym formacie rekordu pliku.
$BadClus. Ten plik zawiera lokalizację każdej z uszkodzonych jednostek alokacji wykrytych podczas pierwszego formatowania lub działań późniejszych. Jeśli wybrano opcję „szybkie formatowanie”, system nie będzie sprawdzał, czy istnieją uszkodzone jednostki alokacji. W systemie plików NTFS wykorzystywana jest właściwość dysków SCSI tzw. sector sparing, co oznacza, że jednostka alokacji nie jest oznaczana jako uszkodzona, o ile wszystkie sektory zapasowe nie są wyczerpane. Rekord $BadClus jest zapisany w standardowym formacie rekordu pliku.
$Secure. Nowy rekord w systemie plików NTFS5, zawierający deskryptor bezpieczeństwa rekordów tablicy MFT. Zgrupowanie deskryptorów bezpieczeństwa, zamiast umieszczenia każdego z nich w odpowiednich rekordach tablicy MFT poprawia wydajność systemu i umożliwia wykonywanie kopii w celu zwiększenia niezawodności systemu. Rekord $Secure jest zapisany w standardowym formacie rekordu pliku.
$UpCase. Ten plik zawiera małe litery w kodzie Unicode i odpowiadające im duże litery. Rekord $UpCase zapisany jest w standardowym formacie rekordu pliku.
$Extend. Nowy rekord w systemie NTFS5 poza podstawowymi szesnastoma rekordami systemu NTFS4, zawiera cztery dodatkowe rekordy metadanych: $Quota, $ObjID, $Reparse i Dziennik Zmian, $UsnJrnl, jeśli taki jest używany dla danego woluminu. Rekord ten zapisany jest w standardowym formacie rekordu katalogu.
$Quota. Rekord $Quota jest katalogiem przechowującym identyfikatory bezpieczeństwa (SID) użytkowników i pliki, których są właścicielami. Dane te są wykorzystywane przez usługę ograniczania obszaru dysku dostępnego dla użytkownika (Quotas). Rekord $Quota istniał w systemie plików NTFS od początku, ale dopiero teraz został wykorzystany. Rekord $Quota jest zapisany jako standardowy katalog.
$ObjID. Nowy rekord w systemie plików NTFS5, zawiera wskaźniki do plików zawierających jednoznaczne identyfikatory globalne (Globally Unique Identifiers - GUID) związane z plikami COM, skrótami i innymi połączeniami (links). Ten rekord stanowi centralną składnicę informacji o połączeniach, wykorzystywaną przez usługę śledzenia połączeń (Link Tracking Service) do znajdowania położenia plików podstawowych po ich przeniesieniu. Pozwala to administratorom przenosić pliki pomiędzy woluminami NTFS5 bez konieczności ręcznego uaktualniania skrótów (shortcuts) lub połączeń COM wskazujących na dany plik.
$Reparse. Nowy rekord w systemie NTFS5. Przechowuje informacje o plikach zawierających dynamiczne wskaźniki lokalizacji danych (reparse points). Wskaźniki te to nowa cecha systemu plików NTFS5. Zasadniczo przeadresowują one aplikację do innej składnicy danych i zawierają program interpretujący strumień bajtów z tej nowej składnicy. Dynamiczne wskaźniki lokalizacji danych są stosowane w Windows 2000 w przypadku wykorzystywania katalogów dołączania (mount points) i usługi Remote Storage Service.
$UsnJrnl. Nowy rekord w systemie plików NTFS5. Jest to standardowy rekord pliku zawierający wpisy do dziennika zmian (Change Journal). Dziennik zmian jest używany do szybkiego odzyskiwania indeksów dodatkowych NTFS5, włącznie z wpisami dokonanymi przez aplikacje dostarczone przez firmy trzecie, które mogą mieć specjalny indeks.

Pojedyncze rekordy są bez znaczenia, o ile nie zna się związanych z nimi atrybutów. W systemie plików NTFS5 zdefiniowano 16 atrybutów dla tablicy MFT, trochę więcej niż w przypadku NTFS4. Niektóre atrybuty, jak np. $File_Name są wykorzystywane dla rekordów wszystkich typów; inne, np. $Volume_Version, używane są tylko dla jednego typu rekordu.

Teoretycznie baza danych systemu plików NTFS jest możliwa do rozszerzenia, ale zgodnie z wiedzą autora, żaden z szeroko dostępnych programów nie modyfikuje tablicy MFT. Dostawca takiego produktu musi przetestować wpływ każdego rozszerzenia tablicy MFT na tysiące aplikacji, tak jak robi to Microsoft w przypadku zmian wprowadzonych w systemie NTFS5.

Budowa tablic FAT i MFT — podsumowanie

Poniżej zamieszczono najważniejsze informacje dotyczące budowy tablicy FAT i MFT:

Tablica FAT, jak również tablica FAT32, jest odwzorowaniem jednostek alokacji danego dysku.
System plików NTFS wykorzystuje do lokalizacji plików i katalogów bazę danych, czyli MFT, a nie odwzorowanie jednostek alokacji.
Katalogi FAT i FAT32 są indeksem jednostek alokacji tego odwzorowania. Katalogi są rozrzucone na całym obszarze dysku.
Katalogi NTFS są integralną częścią MFT i są umieszczane na dysku w dużych kawałkach, co poprawia wydajność i umożliwia sprawdzanie spójności.
Systemy plików FAT i FAT32 mają ściśle określoną strukturę. Struktura MFT jest określona przez ukryte rekordy metadanych, które same są częścią MFT. Struktura rekordu może być rozszerzona o różne typy rekordów i indeksów.
Pliki skasowane nie są usuwane z tablicy FAT. Odpowiednia pozycja w katalogu jest zaznaczona w specjalny sposób, umożliwiający zwolnienie związanych z nią jednostek alokacji. Poważnym problemem jest fragmentacja. Struktura MFT jest odporna na skutki fragmentacji.
Pliki i katalogi NTFS są obiektami chronionymi poprzez zintegrowany system bezpieczeństwa Windows 2000. Pliki i katalogi w systemach plików FAT i FAT32 nie mają żadnej ochrony.
Utrzymywanie spójności systemu plików na dużych woluminach FAT i FAT32 jest trudne z powodu losowego rozmieszczenia struktur katalogu.

Nowe właściwości systemu plików NTFS

Następny paragraf zawiera opis tych atrybutów i ich funkcje w tablicy MFT. Kilka nowych właściwości systemu NTFS5 wprowadzono poprzez modyfikacje rekordów metadanych tablicy MFT, listy atrybutów i standardowej struktury rekordu. Te nowe własności i ich atrybuty to:

Śledzenie połączeń rozproszonych (Distributed Link Tracking). Automatycznie śledzi położenie rekordów dla plików źródłowych wykorzystywanych przez połączenia do skrótów (shortcuts) i obiektów OLE. Usługa ta korzysta z nowego atrybutu, $Object_ID, i nowego rekordu metadanych, $ObjID.

Dynamiczny wskaźnik lokalizacji danych (Reparse Points). Pozwala na dołączanie systemu plików z innych woluminów, takich jak dyski twarde i napędy CD-ROM jako folder w systemie plików NTFS. Umożliwia również zastępowanie pliku wskaźnikami oraz specjalnym programem obsługi takich własności, jak hierarchiczne przechowywanie danych. Usługa ta korzysta z nowego atrybutu, $Reparse, i nowego rekordu metadanych, $Reparse_Point.

Nakładanie ograniczeń przestrzeni dyskowej (Quota Tracking). Pozwala na ograniczanie obszaru dostępnego dla użytkownika na danym woluminie. Usługa ta korzysta z atrybutu $Quota, istniejącego we wcześniejszych wersjach, ale niewykorzystywanego oraz nowego rekordu metadanych, $Quota.
Dziennik zmian (Change Log). Zapewnia aplikacjom indeksującym tablicę MFT szybkie uaktualnienie indeksów bez powtórnego przeszukiwania całej tablicy. Usługa ta korzysta z nowego rekordu metadanych, $UsnJrnl.
System plików zaszyfrowanych (Encrypted File System). Umożliwia szyfrowanie plików w taki sposób, że tylko użytkownik, który je zaszyfrował może je odczytać. Usługa ta korzysta z nowego atrybutu MFT, $Logged_Utility_Streams. Szczegółowe informacje zawarto w rozdziale 15. Pierwsze cztery usługi omówiono w poniższym rozdziale. System plików zaszyfrowanych jest opisany w rozdziale 14.

Szczegółowy opis działania systemu plików NTFS

MFT jest obiektową bazą danych. Obiekty wywodzą się z klas, które zawierają pewne atrybuty. Na przykład rekord pliku zawiera atrybut $Data, a rekord katalogu zawiera atrybut $Index_Root. Wszystkie atrybuty mają dwie części składowe: nagłówek i blok danych. Nagłówek zawiera informacje opisujące ten atrybut, takie jak całkowita liczba bajtów zajmowanych przez atrybut, liczba bajtów przypadająca na każdą z części, przesunięcie liczone od początku atrybutu określające położenie bloku danych, znacznik czasu, wskaźniki stanu itp.

W bloku danych atrybutu zapisane są informacje zgodne z przeznaczeniem tego atrybutu. Na przykład blok danych atrybutu $File_Name zawiera nazwę pliku. Poniżej przedstawiono wydruk zawartości atrybutu $File_Name pliku o nazwie FileName.txt.

<<Wydruk atrybutu $File_Name przedstawiający jego budowę. Blok danych zaznaczono czcionką --> pogrubioną[Author:UP] .>>

30 00 00 00 78 00 00 00 00 00 00 00 00 00 02 00 0...x.............

5A 00 00 00 18 00 01 00 05 00 00 00 00 00 05 00 ..................

F0 98 70 DB 6A BF BE 01 F0 98 70 DB 6A BF BE 01 ..p.j ......p.j...

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................

20 00 00 00 00 00 00 00 0C 03 46 00 69 00 6C 00 ............F.i.l.

65 00 4E 00 61 00 6D 00 65 00 2E 00 74 00 78 00 e.N.a.m.e.....t.x.

74 00 00 00 00 00 00 00 t.......

Budowa nagłówka atrybutu jest jednakowa dla wszystkich typów atrybutów. Nagłówek zawiera:

Pierwsze 4 bajty (30 00 00 00 w powyższym przykładzie) przedstawiają kod typu atrybutu. Pamiętać należy, że bajty zapisane są od najmłodszego do najstarszego i w celu odczytania typu trzeba odwrócić ich kolejność, co w tym przypadku daje kod typu równy 30, wskazując na atrybut $File_Name. System używa kodów typu zamiast nazw, więc atrybuty mogą być posortowane w rekordzie. Pierwszymi atrybutami są te z niższymi kodami typu. Taka zasada powoduje, że niepotrzebne są specjalne rekordy metadanych określające struktury rekordu.

Następne 4 bajty (78 00 00 00) pokazują rozmiar atrybutu, razem z nagłówkiem, wyrażony w bajtach (120 bajtów).

Kolejne 8 bajtów są to bajty rezerwowe.

Następne 4 bajty (54 00 00 00) pokazują rozmiar bloku danych atrybutu, wyrażony w bajtach (90 bajtów).

W kolejnych dwóch bajtach (18 00) zapisane jest przesunięcie (offset) początku bloku danych w stosunku do początku nagłówka (24 bajty).

Następne 10 bajtów zawiera specjalne znaczniki i atrybuty.

W kolejnych 32 bajtach zapisany jest znacznik czasu.

Końcowe 26 bajtów zawiera informacje o lokalizacji, właściwe dla tego atrybutu.

Atrybut nie musi być zapisany całkowicie w rekordzie MFT. Na przykład atrybut $Data rzadko mieści się w rekordzie, który ma rozmiar 1 kB. Jeśli atrybut staje się zbyt duży, system plików pozostawia w rekordzie nagłówek, a blok danych przenosi na dysk poza MFT, pozostawiając wskaźnik pozwalający na lokalizację tego bloku. Taki atrybut nosi nazwę nierezydentnego (nonresident). Niektóre atrybuty muszą pozostać rezydentne ze względu na działanie systemu plików. Takie atrybuty są oznaczone w rekordzie metadanych $AttrDef.

System plików, przenosząc blok danych atrybutu poza MFT, stara się zapisać dane w przyległych jednostkach alokacji, tzw. ciąg (run). Jest to łatwe, o ile wolumin ma dużo wolnej przestrzeni, ale jeśli robi się ciasno i dostępne jednostki alokacji są rozrzucone na całym obszarze dysku, nie ma możliwości zapisania danych w spójnym, ciągłym obszarze kilku jednostek alokacji (jeden ciąg). W tym przypadku dochodzi do fragmentacji pliku i zapisania danych w kilku ciągach jednostek alokacji. Każdemu ciągowi jednostek alokacji odpowiada wskaźnik w rekordzie MFT. Ten wskaźnik składa się z trzech elementów:

Początkowy numer logicznej jednostki alokacji (Logical Cluster Number — LCN). Każda jednostka alokacji ma nadany 64-bitowy numer kolejny tzw. LCN.

Początkowy numer wirtualnej jednostki alokacji (Virtual Cluster Number — VCN). Pojedyncza jednostka alokacji w ciągu jest identyfikowana poprzez numer względny tzw. VCN. Jeśli plik jest zapisany w kilku ciągach jednostek alokacji, to wskaźnik do każdego ciągu zawiera VCN pierwszej jednostki alokacji w tym ciągu.

Liczba jednostek alokacji. Liczba jednostek alokacji w tym ciągu.

Połączenie LCN i VCN we wskaźniku ciągu jednostek alokacji bardzo ułatwia znalezienie określonego bajta w pliku. System plików bierze adres względny bajta, żądany przez aplikację („Przejdź do bajtu 1232 i odczytaj kolejne 100 bajtów”), i dzieli go przez rozmiar jednostki alokacji, aby określić jednostkę alokacji zawierającą wymagany bajt. Następnie przeszukuje rekordy MFT, aby znaleźć ciąg jednostek alokacji zawierający określony numer VCN. Wskaźnik zawierający VCN zawiera również numer LCN początku danego ciągu jednostek alokacji. Jeśli system plików jest coraz bardziej zajęty przez dużą liczbę odwołań, to wtedy nie robi sobie kłopotu z przemieszczaniem głowic dysku tam i z powrotem do MFT, aby uzyskać nowe numery LCN. Zamiast tego przesuwa głowice tam i z powrotem przez cały dysk, chwytając informacje o lokalizacji z MFT, a następnie zbierając dane z wybranych jednostek alokacji, podobnie jak farmerzy zrywają winogrona. Nazywa się to elevator seeking.

Pojęcia ogólne MFT — podsumowanie

Dotychczas opisano następujące pojęcia podstawowe MFT:

Plik lub katalog w rzeczywistości jest rekordem w bazie danych MFT.

Rekord MFT zawiera zestaw atrybutów, które wspólnie określają zawartość pliku lub katalogu.

Atrybuty MFT normalnie zapisane są w rekordach MFT, ale jeśli są zbyt duże, mogą być przeniesione poza MFT na dysk.

Dane z nierezydentnej części atrybutu są umieszczane w zestawie jednostek alokacji zwanym ciągiem (run). Ciągi jednostek alokacji są lokalizowane za pomocą informacji zawartych w bazie danych MFT.

Dane mogą być rozdzielone pomiędzy wiele ciągów jednostek alokacji. Techniki dostępu do plików ograniczają wpływ fragmentacji danych. Jeśli fragmentacja stanie się zbyt dotkliwa, Windows 2000 przeprowadza defragmentację.

Mając na uwadze powyższe pojęcia, przyjrzyjmy się bliżej, w jaki sposób NTFS wykorzystuje te atrybuty rekordów MFT do nadzorowania systemu plików.

Opis funkcjonalny atrybutów MFT

W systemie plików NTFS5 do tworzenia rekordów tablica MFT używa 16 atrybutów. Nazwy atrybutów także zaczynają się od znaku $. Niektóre atrybuty są wspólne dla wszystkich rekordów, tak jak $Standard_Information i $File_Name. Inne mają specjalną funkcję i są wykorzystywane w szczególnych typach rekordów. Na przykład rekord $Volume zawiera atrybuty $Volume_Name i $Volume_Information. W tabeli 13.2 zestawiono listę atrybutów i odpowiednich typów rekordów.

Tabela 13.2. Atrybuty MFT uporządkowane według typu rekordu

$Standard_Information	10
$Attribute_List	20
$File_Name	30
$Object_Id	40**
$Security_Descriptor	50
$Volume_Name	60
$Volume_Information	70
$Data	80
$Index_Root	90
$Index_Allocation	A0
$Bitmap	B0
$Reparse_Point	C0
$Ea_Information (Nie jest używany. Zrezygnowano z kompatybilności z systemem plików HPFS.)	D0
$Ea (Nie jest używany. Zrezygnowano z kompatybilności z systemem plików HPFS)	E0
$Logged_Utility_Stream (Używany w plikach szyfrowanych)	100

**Atrybut systemu plików NTFS4 o nazwie $Volume_Version nie jest używany. Kod typu 40 został przypisany atrybutowi $Object_ID.

W następnych akapitach zamieszczono wyciągi z rekordów MFT w zapisie szesnastkowym. Zadaniem tej analizy jest pokazanie specyfiki MFT i jej wpływu na działanie systemu plików NTFS. Czytelnicy zainteresowani głębszą analizą rekordów NTFS mogą użyć edytora pozwalającego na odczytywanie zawartości dysku w postaci bajtowej i przeszukiwanie według zadanych znaczników.

Przewodnik po kluczowych atrybutach MFT

Opis atrybutów rekordów MFT zamieszczony w tym akapicie stanowi przewodnik po strukturach tablicy MFT. Te informacje pokazują dokładnie, w jaki sposób system plików NTFS wykorzystuje atrybuty plików i katalogów do obsługi wejścia/wyjścia (I/O calls) i pomogą w wykrywaniu błędów NTFS. Poniżej znajduje się lista atrybutów i ich właściwości, która powinna dać pojęcie, dlaczego opis ten jest tak szczegółowy.

$Standard_Information. Zawiera proste atrybuty pliku (tylko do odczytu, systemowy, ukryty i archiwalny) razem z zestawem znaczników czasu określających datę i czas utworzenia pliku, modyfikacji danych, modyfikacji atrybutów i ostatniego dostępu do pliku. Te informacje są wyświetlane w Eksploratorze oraz poprzez polecenie dir.

$File_Name. Zawiera krótką i długą nazwę przypisaną do pliku. Przedstawiono szczegóły algorytmów tworzących nazwy krótkie i omówiono związane z tym problemy. Nazwy plików są również ważne przy indeksowaniu plików, więc znajomość konwencji nazewnictwa pomaga zrozumieć, dlaczego niektóre powszechnie praktykowane czynności, jak np. umieszczenie w jednym katalogu 5000 plików mających w swoich nazwach jednakowych sześć początkowych znaków, nie dają poprawnych rezultatów.

$Security_Descriptor. Rekordy NTFS są obiektami chronionymi. Zrozumienie sposobu ich przechowywania i odczytywania z przypisanych im rekordów tablicy MFT pozwoli na łatwiejsze zrozumienie zagadnień związanych z bezpieczeństwem, które omówiono w następnym rozdziale.

$Data. Wiele nowych cech systemu Windows 2000 wykorzystuje zalety wielokrotnych strumieni danych (multiple data stream) występujących w systemie plików NTFS. W tym paragrafie opisano sposób przechowywania danych oraz wykorzystanie strumieni danych (streams) do raportowania (journaling) i krótkiego opisu plików. W paragrafie tym przedstawiono także szczegóły dotyczące kompresji i obsługi zbiorów „rzadkich” (sparse files).

Atrybuty katalogu (Directory attributes). Budowa i działanie trzech atrybutów związanych z katalogami MFT są czynnikami warunkującymi pewność działania i wewnętrzną spójność systemu plików NTFS. Wiedza o sposobie przechowywania indeksów pozwala na zrozumienie ograniczeń defragmentacji, szyfrowania plików i indeksowania nazw plików.

$MFT i $MFTMirr. W tym paragrafie opisano szczegółowo działanie samej tablicy MFT. Wykorzystując tę wiedzę można lepiej zrozumieć procedurę startową (boot sequence) Windows 2000 i sposoby odtwarzania systemu podane w rozdziale 18.
$Logged_Utility_Stream. Ten atrybut jest związany z systemem plików zaszyfrowanych (Encrypted File System), a jego opis zamieszczono w rozdziale 14.
$Reparse_Point. Ze wszystkich tajemniczych nowych właściwości Windows 2000 dynamiczne wskaźniki lokalizacji danych (reparse points) i usługi wykorzystujące są najczęściej źle rozumiane. Po zapoznaniu się ze sposobem zapisywania i wykorzystania tego atrybutu przez MFT będzie znane również działanie katalogów dołączania (mount points), hierarchicznego przechowywania danych oraz budowa folderu Sysvol, używanego do obsługi grup w domenie.

Typy atrybutów wspólnych

Z szesnastu atrybutów systemu plików NTFS5, dwa pojawiają się we wszystkich typach rekordów. Są to $Standard_Information oraz $File_Name. W każdym rekordzie występuje również 48-bajtowy nagłówek nie związany z żadnym szczególnym typem atrybutu. Nagłówek pliku zawiera numer kolejny pozwalający zidentyfikować rekord w MFT, numer odniesienia pliku określający adres względny rekordu odniesiony do początku woluminu, licznik aktualizacji dla sprawdzania spójności, a także inne parametry rekordu.

$Standard_Information

Atrybut $Standard_Information zawiera informacje powszechnie używane, które muszą pozostać rezydentne w rekordzie MFT. Poniżej przedstawiono wydruk atrybutu $Standard_Information typowego rekordu MFT.

<<Atrybut $Standard_Information>>

10 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 ....'...........

48 00 00 00 18 00 00 00 F0 98 70 DB 6A BF BE 01 H.........p.j...

F0 98 70 DB 6A BF BE 01 F0 98 70 DB 6A BF BE 01 ..p.j.....p.j...

F0 98 70 DB 6A BF BE 01 20 00 00 00 00 00 00 00 ..p.j... .......

00 00 00 00 00 00 00 00 00 00 00 00 03 01 00 00 ................

00 00 00 00 00 00 00 00 50 06 00 00 00 00 00 00 ........P.......

Powyższe 96 bajtów zawiera następujące informacje:

Znaczniki czasu (Time stamps). (F0 98 70 DB 6A BF BE 01) następujących działań: utworzenie, ostatni dostęp, ostatnia modyfikacja atrybutu i ostatnia modyfikacja danych.

Znaczniki atrybutu (Atribute flags) dla podstawowych atrybutów, takich jak: tylko do odczytu, ukryty, systemowy i archiwalny.

Licznik aktualizacji (Update counter), którego wartość zwiększa się o jeden przy każdej zmianie rekordu. NTFS umieszcza kopię licznika aktualizacji w ostatnich dwóch bajtach każdego sektora w rekordzie i wykorzystuje do sprawdzania spójności.

Licznik połączeń (Link counter) zawierający liczbę plików wskazujących na ten rekord. Jest wykorzystywany do zapewnienia zgodności ze standardem POSIX i nie odnosi się do nowej usługi śledzenia połączeń Windows 2000.

Pozycje dotyczące znaczników czasu wymagają dodatkowych objaśnień. Różnica pomiędzy „modyfikacją atrybutu” a „modyfikacją danych” wynika ze sposobu, w jaki system pozostawia w rekordzie ślad modyfikacji. Znacznik czasu w atrybucie $Standard_Information odnosi się do atrybutu $Data, jeśli jest to rekord pliku, albo do atrybutu $Index_Root, jeśli jest to rekord katalogu. Zmiany tych atrybutów zmieniają wartość znacznika czasu ostatniej modyfikacji danych. Zmiany któregokolwiek z pozostałych atrybutów zmieniają wartość znacznika czasu ostatniej modyfikacji atrybutu.

Znacznik czasu ostatniego dostępu (Last Access Time) również nie jest modyfikowany po każdym dostępie do pliku, ale jest zmieniany raz na godzinę niezależnie od tego, ile razy sięgano do tego pliku. Poprawia to wydajność systemu poprzez ograniczenie liczby zapisów do pliku spowodowanych przez Eksploratora przesuwającego się przez katalog i zaglądającego do plików w poszukiwaniu ikon. Okres aktualizacji znacznika czasu ostatniego dostępu dla systemu plików FAT32 jest ustalony na jeden dzień.

Ukrywanie modyfikacji znacznika czasu ostatniego dostępu

Eliminując modyfikacje znacznika czasu ostatniego dostępu można poprawić wydajność systemu plików. W tym celu należy dokonać następującej zmiany w Rejestrze:

Key: HKLM|System|CurrentControlSet|Control|FileSystem

Value: NtfsDisableLastAccessUpdate

Data: 1 (REG_DWORD)

$File_Name

Każdy z rekordów MFT zawiera atrybut $File_Name. Jeśli nazwa pliku nie spełnia standardów nazewnictwa MSDOS (8 znaków - nazwa, 3 znaki - rozszerzenie), w rekordzie są dwa atrybuty $File_Name, jeden dla nazwy długiej pliku, drugi dla automatycznie wygenerowanej nazwy krótkiej. Atrybut $File_Name jest rezydentny. Poniższy wydruk przedstawia dwa atrybuty $File_Name pliku o nazwie Long File Name.txt. Pogrubioną czcionką zaznaczono nagłówki atrybutów. Nagłówki zaczynają się kodem typu 30.

<<Atrybut $File_Name dla nazwy krótkiej pliku.>>

30 00 00 00 78 00 00 00 00 00 00 00 00 00 03 00 0...x...........

5A 00 00 00 18 00 01 00 1C 00 00 00 00 00 01 00 Z...............

5E 7B 88 9A 92 BF BE 01 5E 7B 88 9A 92 BF BE 01 ^{......^{......

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

20 00 00 00 00 00 00 00 0C 02 4C 00 4F 00 4E 00 ..........L.O.N.

47 00 46 00 49 00 7E 00 31 00 2E 00 54 00 58 00 G.F.I.~.1...T.X.

54 00 6D 00 65 00 2E 00 T.m.e...

<<Atrybut $File_Name dla nazwy długiej pliku.>>

30 00 00 00 80 00 00 00 0.......

00 00 00 00 00 00 02 00 66 00 00 00 18 00 01 00 ........f.......

1C 00 00 00 00 00 01 00 5E 7B 88 9A 92 BF BE 01 ........^{......

5E 7B 88 9A 92 BF BE 01 5E 7B 88 9A 92 BF BE 01 ^{......^{......

5E 7B 88 9A 92 BF BE 01 00 00 00 00 00 00 00 00 ^{..............

00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ .......

12 01 4C 00 6F 00 6E 00 67 00 20 00 46 00 69 00 ..L.o.n.g. .F.i.

6C 00 65 00 20 00 4E 00 61 00 6D 00 65 00 2E 00 l.e. .N.a.m.e...

74 00 78 00 74 00 00 00 t.x.t...

Należy zwrócić uwagę na kilka pozycji:

Pierwsza pozycja w bloku danych atrybutu (1C 00 00 00) jest numerem kolejnym katalogu wskazującego na dany plik, zapisanym w MFT. Dla przykładu, niech plik będzie zapamiętany w katalogu o nazwie Dir_One. Z powyższych danych wynika, że temu katalogowi odpowiada dwudziesty ósmy rekord tablicy MFT (1C w zapisie szesnastkowym to w zapisie dziesiętnym 28). Wszystkie pliki i podkatalogi katalogu będą powoływać się na ten numer. System plików NTFS wykorzystuje go do określenia katalogu macierzystego pliku i sprawdzania spójności bazy danych. Jeśli w katalogu Dir_One nie ma pliku Long File Name.txt, ta pozycja atrybutu wymaga naprawy.
Następne 4 bajty to szereg znaczników binarnych. Jednym z nich jest znacznik statusu atrybutu rezydentny/nierezydentny (00 00 01 00). Nazwy plików są zawsze rezydentne.
Kolejne 4 pozycje (5E 7B 88 9A 92 BF BE 01) to znaczniki czasu.
Następne 16 bajtów to bajty rezerwowe.
Kolejna pozycja (20 00 00 00) ma nieudokumentowane przeznaczenie.
Następne 2 bajty znajdujące się bezpośrednio przed początkiem pola tekstowego nazwy pliku (0C 02 dla nazwy krótkiej, 12 01 dla nazwy długiej) spełniają podwójną rolę. Pierwszy bajt zawiera długość nazwy pliku. Ponieważ jest to pojedynczy bajt, więc nazwa długa pliku w systemie plików NTFS jest ograniczona do 255 znaków. Drugi bajt jest wskaźnikiem typu nazwy: 01 — oznacza nazwę długą, 02 — oznacza nazwę krótką, a 03 — nazwę długą spełniającą warunki dla nazwy krótkiej.
Pozostałe bajty to pole tekstowe nazwy pliku zapisane w kodzie Unicode. Unicode wykorzystuje 2 bajty na jeden znak, a ponieważ znaki ANSI zajmują tylko jeden bajt, drugi bajt jest pusty.

Atrybut $File_Name wykorzystywany jest w następujących przypadkach:

Obsługa nazw w kodzie Unicode. Zarówno nazwy krótkie, jak i nazwy długie plików systemu NTFS tworzone są z wykorzystaniem znaków Unicode. Jeśli nazwa krótka jest przeznaczona dla klienta DOS, te znaki przedstawione są jako znaki ANSI. Poniżej przedstawiono wydruk zawartości katalogu będący efektem działania polecenia dir /x, pokazującego nazwy krótkie i nazwy długie plików:

E:\DIR /X

Volume in drive E is NTFS

Volume Serial Number is FC46-A70C

Directory of E:\

06/21/99 10:23p 21 LONGFI~1.TXT Long File Name.txt

1 File 21 bytes

0 Dir 104,342,528 bytes free

Znaki specjalne w nazwach plików. W nazwach długich Windows 2000 można stosować spacje, kropki rozpoczynające nazwy i wewnątrz nazwy i inne znaki spośród zestawu ponad 65000 znaków Unicode. Na przykład można użyć klawiszy Alt-Numkeypad do tworzenia wyszukanych nazw, takich jak: hKep????©₤.txt. Wyjątkiem są następujące znaki: /; :, *, ?, „, <, >, ,, |.
Przechowywanie nazw utworzonych z wykorzystaniem liter dużych i małych. Windows 2000 nie rozróżnia liter dużych i małych w nazwach plików, ale są one zapamiętane i wyświetlane dla klientów 32-bitowych. Na przykład, jeśli zapisano plik o nazwie Multi-Case File Name.txt, to polecenie dir multi* powoduje wyświetlenie nazwy w postaci Multi-Case File Name.txt.
Maksymalna długość nazwy pliku i ścieżki dostępu. Maksymalna długość nazwy pliku wynosi 255 znaków. Taka też jest maksymalna długość ścieżki dostępu, ponieważ rekordy katalogów, które wskazują na dany plik, do określenia długości ścieżki dostępu wykorzystują pojedynczy bajt. Z tego względu nazwy katalogów powinny być jak najkrótsze, szczególnie w przypadku struktury wielopoziomowej.

Nazwy krótkie i nazwy długie

Jeśli w sieci znajdują się klienci DOS lub Windows 3.x, serwer musi tworzyć nazwy krótkie odpowiadające nazwom długim tworzonym przez klientów 32-bitowych. Tworzenie nazw krótkich nie jest takie proste jak mogłoby się wydawać. System nie może po prostu wziąć pierwszych ośmiu znaków nazwy i pierwszych trzech znaków rozszerzenia, uznając zadanie za wykonane. Co się stanie, jeśli kilka plików w danym katalogu zaczyna się od tych samych znaków?

System plików NTFS stosuje dwa algorytmy tworzenia krótkich nazw plików. Obydwa bazują częściowo na nazwach długich, zachowując kilka pierwszych znaków nazwy. Algorytm zmienia się, jeśli 5 lub więcej plików w danym katalogu zaczyna się od tych samych znaków. Pierwszy algorytm jest następujący:

Skasuj wszystkie znaki Unicode nie mające odpowiedników w standardzie ANSI.
Usuń spacje, wewnętrzne kropki i inne znaki niedozwolone w systemie DOS. Nazwa Long.File.Name.Test zmienia się na LongFileName.Test.
Trzy pierwsze znaki po ostatniej kropce potraktuj jako rozszerzenie. LongFileName.Test zmienia się na LongFileName.Tes.
Opuść znaki od siódmego wzwyż. LongFileName.Tes zmieni się na LongFi.Tes.
Dodaj znak ~ (tylda) uzupełniony numerem kolejnym pliku, aby zapobiec dublowaniu się nazw. LongFi.Tes zmieni się na LongFi~1.Tes.
Na koniec zamień litery na duże. Ostateczna postać nazwy pliku Long.File.Name.Test to LONGFI~1.TES.

Piąty i następne pliki o jednakowych pierwszych sześciu literach nazwy są traktowane trochę inaczej:

Opuść znaki Unicode, spacje i nadmiarowe kropki (jak poprzednio).
Trzy pierwsze znaki po ostatniej kropce potraktuj jako rozszerzenie (jak poprzednio).
Opuść znaki od drugiego wzwyż. Na tym etapie Long.File.Name.Test5 zamienia się na Lo.Tes.
Dodaj 4 cyfry szesnastkowe wyznaczone przez algorytm na podstawie opuszczonych znaków nazwy długiej. Long.File.Name.Test5 daje liczbę D623, a Long.File.Name.Test6 daje liczbę E623. Na tym etapie nazwa krótka przybiera postać Lo623.Tes.
Dodaj do nowej nazwy pliku znak ~ (tylda) i następujący po nim numer kolejny w razie gdyby nazwy plików powtarzały się. LoD623.Tes zmieni się na LoD623~1.Tes.
Na koniec zamień litery na duże. Ostatecznie skrócona postać nazwy Long.File.Name.Test5 to LOD623~1.TES.

Środki ostrożności przy stosowaniu długich nazw

Długie nazwy plików są znane od lat, więc użytkownicy są na pewno świadomi, jakie pułapki na nich czyhają. Trzeba koniecznie pamiętać o następujących właściwościach:

Przenoszenie pomiędzy komputerami plików mających nazwy długie. Algorytm tworzenia nazw krótkich stosowany przez Windows 2000/NT i Windows 9x działa inaczej niż jego odpowiedniki NetWare --> LONGNAME.NAM w wersji 4.1x i OS2.NAM w wersji 3.x.[Author:PGon]

Nazwy nadmiernie długie spowalniają działanie systemu plików. Dla optymalnego działania należy przestrzegać zasady, że nazwy plików nie powinny przekraczać 32 znaków. Jeśli wtedy dojdzie do fragmentacji katalogu, to nazwa krótka i nazwa długa mogą zostać rozdzielone.

Ostrzeżenie przed stosowaniem nazw długich w plikach wsadowych. Interpreter poleceń CMD.EXE Windows 2000 nie działa tak samo jak COMMAND.COM. Na przykład używając CMD, przy zmianie katalogu nie jest konieczne zapisywanie długich nazw w cudzysłowie. Można napisać polecenie w postaci cd c:\dir one i przejść w ten sposób do podanego katalogu. Jednakże nie jest to standard dla wszystkich poleceń. Wprowadzenie polecenia del dir one* spowoduje skasowanie wszystkich plików zaczynających się od dir i od one.

Specjalna obsługa rozszerzeń nazw plików. Rozszerzenia nazw plików wpływają na działanie identyfikatorów globalnych (wildcards). Jako przykład weźmy nazwy Long.File.Name.Test1.htm oraz Long.File.Name.Test2.html. Przechodząc do wiersza poleceń i wpisując polecenie wyświetlenia zawartości katalogu dla nazw w postaci *.htm otrzymamy listę zawierającą obydwie nazwy plików zamiast jednej, z rozszerzeniem htm. Wygląda to na błąd raczej nieszkodliwy, ale jaki będzie wynik działania polecenia del *.htm, wydanego w celu skasowania starych plików mających rozszerzenie htm? Zostaną skasowane również wszystkie pliki z rozszerzeniem html.

Aplikacje DOS kasują nazwy długie. Jeśli aplikacja DOS zmieni nazwę krótką pliku, to nazwa długa tego pliku zostanie usunięta. Na przykład, po zmianie nazwy pliku z LONGFI~1.TXT na HOLYMOLY.TXT przez klienta DOS, polecenie dir /x z konsoli serwera wyświetla następujący komunikat:

E:\ DIR /X

Volume in drive E is NTFS

Volume serial number is FC46-A70C

Directory of E:\

06/21/99 10:23p 21 HOLYMOLY.TXT

2 File(s) 21 bytes

0 Dir(s) 104,342,528 bytes free

Oddzielanie rozszerzeń nazw plików przy nazwach długichZmieniając odpowiednią pozycję Rejestru można zmusić system do odfiltrowywania długich rozszerzeń podczas obsługi wiersza poleceń. Powoduje to spowolnienie pracy systemu, dlatego zmiany takiej należy --> dokonywać, jeśli jest potrzebna[Author:UP] .

Key: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem

Value: Win95TruncatedExtentios

Data: 0 (normally set to 1)

$Security_Descriptor

Wszystkie rekordy NTFS są obiektami chronionymi Windows 2000 i jako takie zawierają deskryptor ochrony (security descriptor), który określa, kto jest właścicielem obiektu, kto ma prawo dostępu do obiektu, a kto go nie ma (lista DACL) oraz kto ma prawo inspekcji obiektu (lista SACL). W systemie plików NTFS4 atrybut $Security_Descriptor początkowo jest rezydentny, ale może zostać nierezydentny, jeśli będzie zbyt duży.Rozmiary deskryptora ochrony mogą rosnąć szybciej niż zapaśnik sumo na odpowiedniej diecie. W systemie Windows NT deskryptory ochrony o dużych rozmiarach stają się nierezydentne i rozrzucone po całym dysku, obniżając wydajność i zwiększając czas na rozprzestrzenienie się zmian listy ACL.

W systemie plików NTFS5 atrybuty $Security_Descriptor są od razu nierezydentne. Zapisane są w specjalnym rekordzie MFT o nazwie $Secure. Ponieważ rekordy są zapisane pojedynczo, wiele z nich może odwoływać się do tego samego deskryptora ochrony. Poprawia to wydajność systemu plików przy rozprzestrzenianiu się modyfikacji ACL.

Rekord $Secure jest połączeniem katalogu i rekordu danych. Atrybut danych zawiera strumień danych o nazwie $SDS, w którym zapisano deskryptory ochrony. Ten atrybut zawiera również dwa atrybuty katalogu, $SDH i $SII, z których jeden jest indeksem deskryptorów, a drugi jest kopią indeksu.Podstawowe rekordy metadanych zachowują swoje standardowe deskryptory ochrony. Program ładujący nie będzie działał poprawnie, jeśli nie znajdzie deskryptora ochrony rekordu, obsługa nowego folderu $Secure jest również ograniczona funkcjonalnie.

Atrybuty katalogu $Secure i blokowanie dziedziczenia

Jeśli dziedziczenie ACL jest wyłączone w jakimś punkcie drzewa katalogu, dodawany jest nowy deskryptor ochrony i aby przyznać odpowiednie prawa dostępu w podkatalogach, konieczne jest dokonanie odpowiednich zmian.

Nawet w przypadku centralnych deskryptorów bezpieczeństwa zmiany ACL przenoszące się w dół drzewa katalogu dotykają każdego rekordu MFT, ponieważ system plików modyfikuje znaczniki czasu i liczniki zmian w poszczególnych rekordach. NTFS jest przystosowany do tego rodzaju pracy i wykonuje ją szybko, powodując nieznaczne obniżenie wydajności.

Przy przeniesieniu pliku z woluminu NTFS4 Windows NT do woluminu NTFS5 Windows 2000 dokonuje się konwersji deskryptora ochrony związanego z danym plikiem do nowego formatu i nadania deskryptorowi statusu nierezydentnego. Zasada ta ma zastosowanie w przypadku odtwarzania plików Windows NT z taśmy na dysk twardy komputera z Windows 2000.

Rekordy pliku i atrybut $Data

Pliki są reprezentowane w MFT przez rekord zawierający trzy wspólne atrybuty: $Standard_Information, $File_Name i $Security_Descriptor razem z czwartym atrybutem $Data. Atrybut $Data zawiera nagłówek opisujący lokalizację i rozmiar atrybutu, oraz blok danych.Blok danych atrybutu $Data może być modyfikowany podczas kompresji i szyfrowania lub zastąpiony przez dynamiczny wskaźnik lokalizacji danych (reparse point). Dane zawarte w atrybucie są obsługiwane inaczej w przypadku specjalnego rodzaju pliku tzw. plik „rzadki” (sparse file), co opisano dokładnie w jednym z dalszych paragrafów bieżącego rozdziału. Poniżej przedstawiona zostanie budowa atrybutu $Data.Budowa atrybutu $Data

Wszystkie rekordy plików mają przynajmniej jeden atrybut $Data. Jeśli blok danych atrybutu jest odpowiednio mały — mniejszy niż około 500 bajtów, zależnie od długości nazwy pliku — mieści się w rekordzie MFT. Poniższy wydruk pokazuje, w którym miejscu rekordu MFT znajdują się dane. Atrybut $Data ma kod typu 80 zaznaczony czcionką pogrubioną. Wydruk zawiera również atrybuty $Standard_Information i $File_Name.

<<Atrybut $Standard_Information>>

46 49 4C 45 2A 00 03 00 1D 09 30 00 00 00 00 00 FILE*.....0.....

01 00 01 00 30 00 01 00 60 01 00 00 00 04 00 00 ....0...'.......

00 00 00 00 00 00 00 00 03 00 02 00 00 00 00 00 ................

10 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 ....'...........

48 00 00 00 18 00 00 00 02 24 47 7C 31 BB BE 01 H........$G|1...

02 24 47 7C 31 BB BE 01 02 24 47 7C 31 BB BE 01 .$G|1....$G|1...

02 24 47 7C 31 BB BE 01 20 00 00 00 00 00 00 00 .$G|1... .......

00 00 00 00 00 00 00 00 00 00 00 00 02 01 00 00 ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

<<Atrybut $File_Name>>

30 00 00 00 70 00 00 00 00 00 00 00 00 00 02 00 0...p...........

54 00 00 00 18 00 01 00 05 00 00 00 00 00 05 00 T...............

02 24 47 7C 31 BB BE 01 02 24 47 7C 31 BB BE 01 .$G|1....$G|1...

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

20 00 00 00 00 00 00 00 09 03 73 00 68 00 6F 00 ..........s.h.o.

72 00 74 00 2E 00 74 00 78 00 74 00 00 00 00 00 r.t...t.x.t.....

<<Atrybut $Data. Nagłówek zaznaczony czcionką pogrubioną. Atrybut ma kod typu 80.>>

80 00 00 00 58 00 00 00 00 00 18 00 00 00 01 00 ....X...........40 00 00 00 18 00 00 00 54 68 69 73 20 69 73 20 @.......This is

61 20 73 68 6F 72 74 20 66 69 6C 65 20 74 6F 20 a short file to

75 73 65 20 66 6F 72 20 61 20 73 61 6D 70 6C 65 use for a sample

20 6F 66 20 61 6E 20 4E 54 46 53 20 66 69 6C 65 of an NTFS file

20 65 6E 74 72 79 2E 20 FF FF FF FF 82 79 47 11 entry. .....yG.

Cztery bajty FF FF FF FF wraz z następującym po nich podwójnym słowem 11 47 79 82 (odwrotna kolejność bajtów) oznaczają koniec rekordu NTFS5 i nie są częścią atrybutu $Data.Jeśli atrybut $Data przekracza rozmiar rekordu MFT równy 1 kB, system przenosi blok danych poza MFT na dysk twardy. Nagłówek atrybutu i niewielki fragment danych, zawierający informacje dotyczące części nierezydentnej danych oraz wskaźniki do ciągów danych zapisanych poza MFT, pozostają w tablicy MFT. Tak wygląda nagłówek części rezydentnej po przeniesieniu bloku danych na dysk poza tablicę MFT.

<<końcówka zawartości atrybutu $File_Name>>

20 00 00 00 00 00 00 00 0B 03 62 00 69 00 67 00 ..........b.i.g.

66 00 69 00 6C 00 65 00 2E 00 74 00 78 00 74 00 f.i.l.e...t.x.t.

<<Rezydentny nagłówek nierezydentnego atrybutu $Data. Pogrubioną czcionką zaznaczono informacje o pliku i wskaźniki do nierezydentnych ciągów danych. Plik zapisany jest w sześciu częściach.>>80 00 00 00 50 00 00 00 01 00 00 00 00 00 03 00 ....P...........

00 00 00 00 00 00 00 00 5D 00 00 00 00 00 00 00 ........].......

40 00 00 00 00 00 00 00 00 BC 00 00 00 00 00 00 @...............

80 BB 00 00 00 00 00 00 80 BB 00 00 00 00 00 00 ................

11 0A 16 21 02 F7 2F 11 0C 08 21 46 0C DA 00 FD ...!../...!F....

FF FF FF FF 82 79 47 11 00 00 00 00 00 00 00 00 .....yG.........

Blok danych zamieszczony na wydruku zawiera następujące informacje:

Liczba jednostek alokacji. 5D, w zapisie dziesiętnym 93. Jest to całkowita liczba jednostek alokacji zawierających plik, włączając w to ciągi jednostek alokacji, które uległy fragmentacji.

Rezerwowe. Kolejne 4 bajty są bajtami rezerwowymi.

Rozmiar na dysku. BC00 w zapisie dziesiętnym 48,128. Ta wartość zawiera również nieużywaną część końcowej jednostki alokacji, jest zawsze parzystą wielokrotnością rozmiaru jednostki alokacji.
Rozmiar pliku. BB80 w zapisie dziesiętnym 48,000. Ta wartość jest podawana w wierszu poleceń i przez interfejs użytkownika jako rozmiar pliku.
Znaczniki. 00 00 00 40. Zestaw znaczników takich operacji na plikach, jak kompresja czy szyfrowanie.
Wskaźnik lokalizacji. Zawiera następujące informacje w postaci spakowanej: numer logicznej jednostki alokacji oraz numer wirtualnej jednostki alokacji, będącej początkiem ciągu danych nierezydentnych, a także liczba jednostek alokacji zajętych przez ten ciąg danych.

Z czasem, jak użytkownicy dodają do pliku coraz więcej informacji, plik rośnie i staje się coraz bardziej pokawałkowany. To powoduje dokładanie wskaźników do rekordu MFT. Po przekroczeniu przez pole wskaźników rozmiaru rekordu MFT równego 1 kB, co może się przydarzyć w przypadku wysokiej fragmentacji pliku, dla pozostałych wskaźników system zajmuje kolejny rekord MFT.Kiedy atrybuty są rozdzielone pomiędzy rekordami, NTFS umieszcza atrybut $Attribute_List w pierwszym rekordzie MFT aby śledzić dodatkowe rekordy MFT i ich odwzorowanie. Taki przypadek zdarza się rzadko. W postaci spakowanej wskaźnik zajmuje tylko 4 bajty, więc rekord MFT o rozmiarze 1 kB może pomieścić wskaźniki do ponad dwustu ciągów danych. W normalnych warunkach przeprowadza się defragmentację dysku, zanim pliki będą składać się z dwustu kawałków. Jednak może dojść do takiej fragmentacji woluminu, że pojawi się kilka egzemplarzy rekordu pliku zawierających atrybut $Attribute_List. Autor powołuje się na świadectwo osób serwisujących komputery pracujące pod kontrolą systemu Windows NT 3.51 od czasu jego pojawienia się, w których nie przeprowadzono żadnej defragmentacji dysku twardego.

Wielokrotne atrybuty $Data

Domyślnie atrybut $Data nie ma nazwy. Kiedy aplikacja wysyła wywołanie interfejsu API zapisu lub odczytu z pliku, NTFS dostarcza zawartość atrybutu $Data bez nazwy. Do rekordu pliku można dodać więcej atrybutów $Data. Blok danych atrybutu $Data nosi nazwę strumień (stream), a dodatkowe atrybuty $Data określane są jako strumienie definiowane przez użytkownika (named data streams). Poniższy przykład pokazuje działanie tego rodzaju strumieni (named data stream):

Utwórz plik o nazwie Superman.txt kopiując kilka znaków z wiersza poleceń:

C:\>echo It's a bird > Superman.txt

W ten sposób zostanie utworzony rekord MFT dla pliku o nazwie Superman.txt z atrybutem danych bez nazwy, zawierającym ciąg znaków It's a bird. Wydruk atrybutu $Data bez nazwy wygląda następująco:

<<Końcowa część atrybutu $File_Name>>

20 00 00 00 00 00 00 00 0C 03 53 00 75 00 70 00 ..........S.u.p.65 00 72 00 6D 00 61 00 6E 00 2E 00 74 00 78 00 e.r.m.a.n...t.x.

74 00 00 00 00 00 00 00 t.......

<<Atrybut $Data bez nazwy, blok danych zaznaczony czcionką p --> ogrubioną[Author:UP] >>

80 00 00 00 28 00 00 00 ....(...

00 00 18 00 00 00 01 00 0F 00 00 00 18 00 00 00 ................

49 74 27 73 20 61 20 62 69 72 64 2E 20 0D 0A 00 It's a bird. ...

FF FF FF FF 82 79 47 11 00 00 00 00 00 00 00 00 .....yG.........

Dodaj drugi atrybut danych kopiując inny tekst do strumienia z nazwą zdefiniowaną przez użytkownika (named stream):

C:\>echo It's a plane. > superman.txt:stream1

Dodaj trzeci atrybut danych z inną nazwą strumienia danych:

C:\>echo It's SUPERMAN. > superman.txt:stream2

Poniższy wydruk rekordu pliku przedstawia trzy atrybuty $Data. Należy zwrócić uwagę na trzy atrybuty Typ 80. Pierwszy atrybut z nazwą zapisany jest --> czcionką pogrubioną, drugi kursywą[Author:UP] .

<<Końcowa część atrybutu $File_Name>>

20 00 00 00 00 00 00 00 0C 03 53 00 75 00 70 00 .... .....S.u.p.

65 00 72 00 6D 00 61 00 6E 00 2E 00 74 00 78 00 e.r.m.a.n...t.x.

74 00 00 00 00 00 00 00 t......

<<Atrybut $Data bez nazwy>>

80 00 00 00 28 00 00 00 ....(...

00 00 18 00 00 00 01 00 0F 00 00 00 18 00 00 00 ................

49 74 27 73 20 61 20 62 69 72 64 2E 20 0D 0A 00 It's a bird. ...

<<Pierwszy atrybut $Data o nazwie stream1>>

80 00 00 00 38 00 00 00 00 07 18 00 00 00 03 00 ....8...........

10 00 00 00 28 00 00 00 73 00 74 00 72 00 65 00 ....(...s.t.r.e.

61 00 6D 00 31 00 00 00 49 74 27 73 20 61 20 70 a.m.1...It's a p

6C 61 6E 65 2E 20 0D 0A lane. ..

<<Drugi atrybut $Data o nazwie stream2>>

80 00 00 00 40 00 00 00 ....@...00 07 18 00 00 00 04 00 11 00 00 00 28 00 00 00 ............(...

73 00 74 00 72 00 65 00 61 00 6D 00 32 00 00 00 s.t.r.e.a.m.2...

49 74 27 73 20 53 55 50 45 52 4D 41 4E 2E 20 0D It's SUPERMAN. .

0A 00 00 00 00 00 00 00 FF FF FF FF 82 79 47 11 .............yG.

Niewiele aplikacji korzysta ze strumieni z nazwą zdefiniowaną przez użytkownika (named stream). Najprostszym sposobem obejrzenia zawartości pliku jest użycie polecenia more:

C:\>more <superman.txtIt's a bird.

C:\>more < superman.txt:stream1

It's a plane.

C:\>more < superman.txt:stream2

It's SUPERMAN.

Na pierwszy rzut oka strumienie danych z nazwą definiowaną przez użytkownika mogą umożliwić tworzenie nowych, innowacyjnych aplikacji. Tak również myślano w firmie Microsoft. Jednakże właściwie tylko w jednym programie, Services for Macintosh (SFM) firmy Microsoft, wykorzystano strumienie danych w znaczącym stopniu. Wolumin SFM wykorzystuje strumienie do obsługi plików rozgałęzionych (dual-fork files) Macintosha.

Baza danych Podsumowanie (Summary) i strumienie danych

Nowe usługi Windows 2000 wykorzystują strumienie danych definiowane przez użytkownika w trochę mniej ambitny sposób niż SFM. Po otwarciu okna Properties (Właściwości) pliku można zauważyć, że zakładka Podsumowanie (Summary) znajduje się za zakładką Security (Ochrona). Na rys.13.2 pokazano przykładowe okno.

0x01 graphic

Rysunek 13.2. Zakładka Summary (Podsumowanie) dla typowego pliku.

Informacje wpisane do odpowiednich pól bazy danych Podsumowanie (Summary) są zapisywane w rekordzie pliku jako ciąg strumieni $Data z nazwą zdefiniowaną przez użytkownika. Poniższy wydruk przedstawia atrybut $Data bez nazwy dla bazy danych Podsumowanie (Summary).

<<Atrybut $Data bez nazwy>>00000000 80000000 48000000 00001800 00000100 ....H...........

00000016 2D000000 18000000 54657874 206F6620 -.......Text of

00000032 66696C65 3120696E 20746865 20756E6E file1 in the unn

00000048 616D6564 20244461 74612061 74747269 amed $Data attri

00000064 62757465 2E000000 bute....

<<Pierwszy atrybut $Data z nazwą, DocumentSummaryInformation. Liczba przy końcu atrybutu, zaznaczona --> pogrubioną czcionką[Author:UP] , jest wskaźnikiem do nierezydentnego bloku danych.>>

80000000 80000000 ........

00000080 011B4000 00000D00 00000000 00000000 ..@.............

00000096 00000000 00000000 78000000 00000000 ........X.......

00000112 00020000 00000000 9C000000 00000000 ................

00000128 9C000000 00000000 05004400 6F006300 ..........D.o.c.

00000144 75006D00 65006E00 74005300 75006D00 u.m.e.n.t.S.u.m.

00000160 6D006100 72007900 49006E00 66006F00 m.a.r.y.I.n.f.o.

00000176 72006D00 61007400 69006F00 6E000000 r.m.a.t.i.o.n...

00000192 11011F00 1F000000 ..........

<<Drugi atrybut $Data z nazwą. Jest to standardowy znacznik używany dla wszystkich pól bazy danych Podsumowanie Summary Information, będący akronimem nazwy "Windows development engineer".>>

80000000 80000000 ......

00000208 011B4000 00000700 00000000 00000000 ..@.............00000224 00000000 00000000 78000000 00000000 ........X.......

00000240 00020000 00000000 A8000000 00000000 ................

00000256 A8000000 00000000 05005300 65006200 ..........S.e.b.

00000272 69006500 73006E00 72004D00 6B007500 i.e.s.n.r.M.k.u.

00000288 64007200 66006300 6F004900 61006100 d.r.f.c.o.I.a.a.

00000304 6D007400 79006B00 64004400 61000000 m.t.y.k.d.D.a...

00000320 21010E30 00300000 !..0.0

<<Jeszcze jeden atrybut $Data z nazwą. Zawiera GUID (nazywany również Class ID lub CLSID) pliku, pomagający w śledzeniu pliku, który został skopiowany w inne położenie.

80000000 68000000 h...

00000448 00261800 00000300 00000000 68000000 .&..........h...00000464 7B003400 63003800 63006300 31003500 {.4.c.8.c.c.1.5.

00000480 35002D00 36006300 31006500 2D003100 5.-.6.c.1.e.-.1.

00000496 31006400 31002D00 38006500 34003100 1.d.1.-.8.e.4.1.

00000512 2D003000 30006300 30003400 66006200 -.0.0.c.0.4.f.b.

00000528 39003300 38003600 64007D00 00000000 9.3.8.6.d.}.....

00000544 FFFFFFFF 82794711 ......yG

Część nierezydentna każdego ze strumieni zdefiniowanych przez użytkownika jest przechowywana w specjalnych buforach wskazywanych przez bazę danych Summary Information. Te bufory są poprzedzone dwoma bajtami FEFF. Poniżej przedstawiono wydruk zawartości bufora:

<<Bufor Summary Information zawierający dane wprowadzone w oknie Summary (Streszczenie).>>

FEFF0000 05000200 00000000 00000000 ................00000000 00000000 01000000 02D5CDD5 ................

9C2E1B10 93970800 2B2CF9AE 30000000 ........+,..0...

6C000000 03000000 01000000 28000000 l...........(...

00000080 30000000 02000000 38000000 ....0.......8...

00000000 00000000 02000000 B0040000 ................

1300000009040000 1E000000 2A000000 ............*...

49006E00 73006500 63007400 20004900 I.n.s.e.c.t. .I.

6E006600 6C006100 6D006D00 61007400 n.f.l.a.m.m.a.t.

69006F00 6E007300 00000000 00000000 i.o.n.s.........

--> Dzięki bazie danych Podsumowanie (Summary Information Database) wartości wprowadzone w oknie Summary (Streszczenie) dla jednego pliku stają się listą wyboru dla wszystkich innych plików. Dla przykładu powiedzmy, że użytkownik pracował całą noc z arkuszem kalkulacyjnym Excela. Po zamknięciu pliku otworzył okno Properties|Summary (Właściwości|Podsumowanie) i wprowadził w polu Category (Kategoria) następujące określenie: Miserable Stinking Report for a Miserable Stinking Boss (Żałosny, śmierdzący raport dla żałosnego, śmierdzącego szefa). To określenie pojawia się w polu Category (Kategoria) dla wszystkich plików wykorzystywanych przez użytkownika z danej stacji roboczej. Baza danych Summary Information kontroluje dostęp do pól na podstawie GUID użytkownika, a nie listy ACL skojarzonych plików. Kategoria „Stinking Boss” zastosowana do konkretnego pliku może być widziana przez innych użytkowników korzystających z tego pliku, ale lista wyboru z wpisaną kategorią „Stinking Boss” pojawi się tylko dla użytkownika, który utworzył plik.[Author:PGon]

Kopiując plik zawierający podsumowanie do serwera Windows NT, kopiowane są również strumienie zdefinowane przez użytkownika (named streams), które zawierają podsumowanie. Są widoczne dla klientów Windows 2000 korzystających z pliku, ale nie można ich zobaczyć pracując z Windows NT, ponieważ interfejs użytkownika nie jest odpowiednio zaprogramowany. Inne, bardziej ambitne, próby wykorzystania strumieni danych zakończyły się fiaskiem z powodu problemów ze współdziałaniem usług Windows 2000. Na przykład usługa Native Structure Storage (NSS) nie pracowała poprawnie w trakcie testów beta. Ta usługa wykorzystuje strumienie danych zdefiniowanych przez użytkownika w połączeniu z dynamicznymi wskaźnikami lokalizacji danych (sposób na przeadresowanie pliku do innego miejsca w systemie plików — co opisano w paragrafie pod tym samym tytułem zamieszczonym w dalszym ciągu bieżącego rozdziału) do przechowywania złożonych dokumentów Microsoft Office. Niestety, kiedy dokument NSS został przeniesiony na platformę programową nie obsługującą strumieni ani dynamicznych wskaźników lokalizacji danych, na przykład Windows NT, dane ginęły. Liczba protestów wniesionych przez beta testerów spowodowała usunięcie usługi NSS z ostatecznej wersji Windows 2000. Lekcja, jaka wynika z tego doświadczenia, jest jasna. Wykorzystując różne systemy operacyjne z różnymi systemami plików, nie należy używać usług, których nie można przenosić.

Strumienie danych i bezpieczeństwo sieciowe

Na strumienie danych zwrócono uwagę w roku 1999 z powodu dziur w zabezpieczeniach związanych z IIS. Wykorzystując te luki możliwe było ujawnienie danych wewnątrz ASP lub skryptów CGI zamiast zwykłego uruchomienia skryptu. Wykonuje się to wprowadzając adres URL do skryptu, a następnie podanie atrybutu $Data na końcu adresu, np. http://www.anyserver.com/somescript .asp:: $Data.

Oglądanie zawartości skryptu zamiast jego wykonania przez wielu administratorów WWW nie jest doceniane. --> Nie jest to luka jak wyłom w systemie zabezpieczeń, ponieważ użytkownik musi mieć katalog, w którym zapisywane skrypty, udostępniony do czytania. Tę lukę usunięto za pomocą SP4 i pozostaje ona w Windows 2000.[Author:UP]

Przed omówieniem dalszych atrybutów MFT należy zwrócić uwagę na dwie specjalne usługi, związane z atrybutem $Data: kompresję i obsługę plików „rzadkich” (sparse files). Szyfrowanie danych również wpływa na atrybuty $Data, co zostanie omówione w rozdziale 14.

Kompresja plików

Jak mówi przysłowie, w przypadku przechowywania danych na dysku twardym, nigdy nie jest on za duży i zbyt szybki. Nawet w erze, kiedy dysk twardy SCSI 50 GB z kontrolerem bardziej inteligentnym niż statek Apollo podczas lotu na Księżyc można mieć za mniej niż 2000 USD, w wielu przypadkach niełatwo jest --> otrzymać[Author:UP] czy dołączyć nowy dysk. Poza tym, kto chciałby spędzić cenny weekend przebudowując macierz dyskową RAID i doglądając transferu danych z kasetki tylko dlatego, że użytkownik chce zapisać pocztę elektroniczną, wraz z załącznikami graficznymi, z ostatnich pięciu lat?

Dla serwera kompresja nie jest rozwiązaniem problemów z przechowywaniem danych, ale może pomóc do czasu uruchomienia nowego nośnika danych. Kompresja jest dobrą alternatywą dla stacji roboczych. Pozwala na zaoszczędzenie pieniędzy i kłopotów z dołączaniem nowych dysków do starych komputerów. Jednak zainstalowanie nowego dysku prawdopodobnie będzie niezbędne do zapisania plików systemowych Windows 2000 Professional, ale jest to wyjątek od reguły.

Opis funkcjonalny kompresji plików

W systemie plików NTFS można kompresować pojedynczy plik, wszystkie pliki w katalogu lub wszystkie pliki woluminu. Algorytm kompresji zachowuje równowagę pomiędzy szybkością działania a oszczędnością przestrzeni dyskowej. Na przykład algorytm zastosowany w programie DriveSpace dla Windows 9x w poszukiwaniu wzorca sprawdza każde dwa bajty, natomiast NTFS każde trzy bajty. Taka procedura jest trochę mniej dokładna, ale znacznie szybsza. Algorytm kompresji zastosowany w systemie plików NTFS testuje i kompresuje pliki rozpatrując kolejno po 16 jednostek alokacji, a nie od razu cały ciąg danych (run). To pozwala systemowi przeanalizować czy w ogóle warto kompresować te dane. W nagłówku pliku znajduje się znacznik kompresji. Jeśli jest ustawiony, system plików kompresuje plik przy zapisywaniu i dekompresuje go w locie przy odczytywaniu. Katalogi również mają znacznik kompresji. Ustawienie znacznika kompresji katalogu powoduje ustawienie znaczników kompresji wszystkich plików w tym katalogu. Nowe pliki utworzone w danym katalogu lub do niego skopiowane będą także kompresowane. Istniejące pliki nie są kompresowane, jeśli nie jest wybrana specjalna opcja interfejsu użytkownika.

Dodatkowy znacznik w nagłówku atrybutu $Data wskazuje na wykorzystywany sposób kompresji. Pozwoli to na zastosowanie w przyszłości nowych algorytmów kompresji. Szczegóły dotyczące działania algorytmu kompresji zastosowanego w Windows 2000 wykraczają poza zakres tej książki. Więcej informacji na ten temat można znaleźć w rozdziale dotyczącym systemu plików NTFS w książce Davida Solomona Inside Windows NT (Microsoft Press; ISBN: 1572316772).

Załączanie kompresji

Ani interfejs użytkownika, ani klucze Rejestru nie dają możliwości zmiany sposobu kompresji, można jedynie ustawiać i kasować znacznik kompresji. Dokonuje się tego używając Eksploratora lub narzędzia COMPACT, uruchamianego z wiersza poleceń. Jako pierwszy sposób zostanie omówione wykorzystanie Eksploratora.

Procedura 13.1 Załączanie kompresji

Otwórz Eksploratora lub Mój komputer i przejdź do pliku lub katalogu, który ma być kompresowany.
Kliknij na ikonie prawym klawiszem myszy i z menu wybierz opcję Właściwości (Properties). Otworzy się okno Właściwości (Properties). (Rys. 13.3).

0x01 graphic

Rysunek 13.3. Okno Właściwości (Properties) przedstawiające informacje o dużym pliku w stanie nieskompresowanym.

W polu Atrybuty (Attributes) naciśnij przycisk Zaawansowane (Advanced). Pojawi się okno Atrybuty Zaawansowane (Advanced Attributes). W oknie tym można kontrolować stan różnych znaczników atrybutów w rekordach MFT. Więcej informacji zawarto w uwagach pod tytułem Wykorzystywanie zaawansowanych atrybutów plików.

0x01 graphic

13.4. Okno Atrybuty Zaawansowane (Advanced Attributes) pokazuje status atrybutów pliku dotyczących kompresji i szyfrowania.

Wykorzystywanie zaawansowanych atrybutów plików

W oknie Zaawansowane Atrybuty (Advanced Attributes) pliku lub folderu wyświetlonych jest kilkanaście opcji mających wpływ na przechowywanie plików. Oto one:

Bit Archiwizuj (Archive) pochodzący z systemu Windows NT i DOS. Sygnalizuje, że plik był zmieniony, ale nie wykonano kopii.

Bit Indeksuj (Index) wprowadzony w Windows 2000, wskazuje, że usługa Content Index Service (CISVC) powinna przeszukać dany plik. Usługa ta pojawiła się jako dodatkowy program indeksujący dla Internet Information Server, a teraz przedostała się do systemu operacyjnego. Na szczęście domyślnie ta usługa jest wyłączona.

Atrybut Kompresuj (Compress) powoduje dokonanie kompresji pliku przez system.

Atrybut Szyfruj (Encrypt) powoduje zaszyfrowanie pliku.

Atrybuty Kompresuj (Compress) i Szyfruj (Encrypt) są wzajemnie wykluczające się z dwóch powodów:

W plikach zaszyfrowanych jest bardzo mało podobnych znaków, więc firma Microsoft nie uznaje ich za dobrych kandydatów do kompresji.

System nie potrafi odtworzyć z taśmy skompresowanych plików zaszyfrowanych. Proces odtwarzania plików (Restore process) odczytuje z taśmy nagłówek pliku skompresowanego, aby znaleźć początkową jednostkę alokacji na dysku, z którego pochodzi dany plik. Proces odtwarzania (Restore process) pracując jako Backup Operator nie potrafi przeczytać pliku zaszyfrowanego w celu znalezienia docelowej jednostki alokacji.

Wybierz opcję Kompresuj zawartość (Compress Contents to save disk space), kliknij przycisk OK, aby zapamiętać zmianę i zamknij okno.
Naciśnij przycisk OK, aby zastosować powyższą zmianę, a następnie zamknij okno Właściwości (Properties). Czas trwania kompresji pliku jest zależny od rozmiaru pliku.
Zamknij okno Właściwości (Properties) i otwórz je ponownie. Wartość parametru Rozmiar na dysku (Size on disk) jest rozmiarem pliku skompresowanego.

Kompresja plików z wykorzystaniem polecenia COMPACT

Dla tych, którzy wolą narzędzia dostępne poprzez linię poleceń, do kompresji i dekompresji plików przeznaczony jest program COMPACT. Ustawienie znacznika kompresji następuje poprzez polecenie compact /c. Skasowanie znacznika kompresji następuje poprzez polecenie compact /u.

W celu ustawienia znacznika kompresji dla katalogu i skompresowania wszystkich plików w nim zapisanych uruchom polecenie w postaci compact /c /s.

Uruchomienie polecenia w postaci compact bez żadnych parametrów powoduje wyświetlenie listy plików i informacji o kompresji. Poniżej przedstawiono listę standardowych plików BMP Windows 2000 dostępnych w systemie w postaci skompresowanej:

C:\TestDir\compact

Listing C:\TestDir\be compressed.

New files added to this directory will not.

1272 : 1024 = 1.2 to 1 C Blue Lace 16.bmp

17062 : 17062 = 1.0 to 1 C Coffee Bean.bmp

16730 : 15872 = 1.1 to 1 C FeatherTexture.bmp

17336 : 13312 = 1.3 to 1 C Gone Fishing.bmp

Of 4 files within 1 directories

4 are compressed and 0 are not compressed.

46,310 total bytes of data are stored in 32,430 bytes.

The compression ratio is 1.2 to 1.

Kompresja a wydajność

Kompresja powoduje znaczące obniżenie wydajności serwerów plików (file server) i serwerów drukowania (print server). Według danych opublikowanych przez firmę Microsoft jest to zakres od 5% do 15%. Doświadczenie autora wskazuje na dużo większe pogorszenie się przepustowości.

Dokładne dane ilościowe są trudne do uzyskania, ponieważ do działających serwerów podłączone są setki użytkowników wykorzystujących w sobie tylko wiadomych celach aplikacje, osobiste bazy danych, pliki z danymi tysięcy różnych sprzedawców i inne. Zastosowanie kompresji ogólnie w całym tym bałaganie uczyni z administratora osobę niepopularną. Lepszym rozwiązaniem jest kompresja osobistych plików użytkowników na serwerze. Przy przenoszeniu danych należy wziąć pod uwagę, że użytkownicy mogą kompresować swoje pliki.

Kompresja plików — podsumowanie

Praca z plikami skompresowanymi w otoczeniu produkcyjnym może być źródłem wielu niespodzianek. Poniżej podano wytyczne, o których należy koniecznie pamiętać:

Ustawienie znacznika kompresji dla katalogu wpływa tylko na pliki utworzone w tym katalogu.
Znacznik kompresji znajduje się w nagłówku atrybutu $Data, a nie w samych danych. Każda operacja tworząca nowy plik dziedziczy stan znacznika kompresji katalogu macierzystego. Kopiowanie pliku powoduje utworzenie nowego atrybutu $Data, więc skopiowany plik dziedziczy stan znacznika kompresji swojego nowego katalogu. Przenoszenie pliku zachowuje atrybut $Data, więc plik przeniesiony zachowuje stan swojego znacznika kompresji niezależnie od ustawień swojego nowego katalogu.
Przy przenoszeniu pliku pomiędzy woluminami NTFS tworzony jest nowy plik, który przejmuje stan znacznika kompresji swojego nowego folderu.
Algorytmy kompresji w systemach plików NTFS4 i NTFS5 są takie same. W przypadku komputera z systemem operacyjnym wybieranym przy starcie (dual-boot) i woluminem sformatowanym w systemie plików NTFS4, pliki skompresowane znajdujące się na tym woluminie są widziane przez system Windows 2000.

Algorytm kompresji DriveSpace nie jest zgodny z algorytmem zastosowanym w systemie plików NTFS. Windows 2000 nie potrafi odczytać woluminów skompresowanych z użyciem programu DriveSpace. Jeśli przesłano plik poprzez sieć z woluminu Windows 9x skompresowanego za pomocą DriveSpace do woluminu Windows 2000 NTFS, to dziedziczy on znacznik kompresji katalogu macierzystego.

Podczas kopiowania lub przenoszenia pliki są zawsze najpierw dekompresowane, nawet jeśli katalog przeznaczenia jest skompresowany. Programy archiwizujące wykorzystują do otwierania plików standardowe wywołania interfejsu API systemu plików, więc pliki archiwizowane są dekompresowane. Pozwala to uniknąć problemów zgodności pomiędzy różnymi systemami archiwizacji, dokonującymi kompresji programowej lub sprzętowej, ale spowalnia archiwizację.

Pliki skompresowane po archiwizacji zachowują znacznik kompresji. W trakcie odtwarzania są ponownie kompresowane bez względu na stan znacznika kompresji katalogu macierzystego.

Odtwarzanie plików skompresowanych może stanowić wyzwanie. Plik jest odczytywany z taśmy w postaci zdekompresowanej. System ma ustalony okres czasu na skompresowanie pliku. Jeśli wolny obszar na dysku jest ograniczony, proces odtwarzania pliku może zakończyć się niepowodzeniem, ponieważ system nie może wepchnąć plików do woluminu odpowiednio szybko, aby nadążyć za odczytywaniem z taśmy. Jedynym sposobem ominięcia tego problemu jest odtworzenie plików do woluminu z dużym obszarem wolnym, a następnie ręczne skopiowanie plików na właściwe miejsce.

Ostrożnie ze statystyką dysku podawaną przez Eksploratora. Lista plików w katalogu pokazuje pliki skompresowane na niebiesko (jeśli ta opcja Właściwości Folderu (Folder Properties) jest wybrana), ale rozmiar pliku podany jest dla pliku nieskompresowanego.

Woluminy skompresowane mogą mieć wysoki stopień fragmentacji. Proces defragmentacji woluminu skompresowanego nie daje rezultatów, więc stosowanym powszechnie przez administratorów sposobem rozwiązania problemu fragmentacji takiego woluminu jest zakup nowego dysku i odtworzenie plików z taśmy.

Pliki „rzadkie” (Sparse files)

Bazy danych oraz programy do przetwarzania obrazów mają przydzielone duże obszary dysku, których nie zapełniają. Nowy pakiet SDK dla Windows 2000 zawiera specjalny zestaw wywołań interfejsu programisty API (API calls), za pomocą których można zbudować struktury zwane zbiorami „rzadkimi” (sparse files). Plik „rzadki” ma określony rozmiar, ale w rzeczywistości nie wymaga obszaru na dysku, dopóki plik nie zaczyna być wypełniany danymi. Ponieważ pliki rzadkie są obsługiwane na poziomie aplikacji, oszczędności obszaru dysku nie są okupione pogorszeniem wydajności, jak to się dzieje w przypadku zwykłej kompresji plików. Nie można utworzyć pliku „rzadkiego” wypełniając po prostu zbiór tekstowy zerami ani budując ogromną bazę danych z niewykorzystanymi rekordami. Pliki „rzadkie” wymagają specjalnych wywołań API (API calls) wysyłanych przez aplikację. Jeszcze zapewne jest zbyt wcześnie, by aplikacje wykorzystywały zalety takich plików, ponieważ jest to nowość w systemie Windows 2000. Najbardziej znaczącą aplikacją wykorzystującą pliki „rzadkie” jest Content Indexer, który zapisuje informacje katalogowe w postaci pliku „rzadkiego”.

Do obsługi plików „rzadkich” nie są dostępne żadne ustawienia parametrów systemu ani zmiany w Rejestrze i dlatego jest to najbardziej „przezroczysta” właściwość NTFS5. Jednym ze sposobów, w jaki właściwość ta wychodzi na jaw, jest nakładanie ograniczeń obszaru dysku dostępnego dla użytkownika (Quota). Obszar dysku przydzielony dla pliku „rzadkiego” liczy się na niekorzyść nałożonego ograniczenia, nawet jeśli rozmiar pliku ma wartość znacznie mniejszą niż ustawiona wartość ograniczenia.

Można próbować wytłumaczyć użytkownikowi istotę obsługi plików „rzadkich” oraz specjalne właściwości takich plików. Można także dopuścić do „zderzania się” użytkownika z nałożonymi ograniczeniami, ponieważ wiadomo, że plik „rzadki” w rzeczywistości nie zajmuje miejsca na dysku. Trzeba jednak być czujnym. Dzisiejszy plik „rzadki” to przyszły 300 megabajtowy potwór.

Rekordy katalogów

Aby umożliwić szybsze przeglądanie, baza danych powinna być poindeksowana. Wszystkie systemy plików Windows 2000, tak jak prawie każdy system plików ogólnego przeznaczenia, indeksują bazę danych według nazwy pliku. NTFS zapisuje ten indeks w rekordzie, którego typ nazwany jest katalogiem. Taki rekord zawiera zwykłe atrybuty, tak jak rekord pliku, ale zamiast atrybutu $Data zawiera trzy atrybuty specjalne do tworzenia list, sortowania i lokalizowania plików i podkatalogów. Są to atrybuty: $Index_Root, $Index_Allocation i $Bitmap.

Atrybut $Index_Root

Atrybut $Index_Root zawiera kopię atrybutu $File_Name wszystkich plików i podkatalogów. Nie należy mylić atrybutu $Index_Root z katalogiem głównym (Root directory), $\. Katalog główny jest specjalną postacią typu rekord katalogu. Ten katalog mieści się wraz z innymi ważnymi rekordami metadanych w tablicy MFT, więc program ładujący (bootstrap loader) może je znaleźć bez błądzenia po omacku.

Weźmy pod uwagę katalog o nazwie \Dir_One, w którym zapisano plik o nazwie FILE_1.TXT. Rekord metadanych $\ - katalog główny - zawiera atrybut $Index_Root, w którym jest kopia atrybutu $File_Name dla katalogu Dir_One.

W rekordzie MFT dla katalogu Dir_One zapisany jest atrybut $Index_Root zawierający kopię atrybutu $File_Name pliku FILE_1.TXT. Każdy atrybut $File_Name zawiera pozycję wskazującą numer kolejny MFT swojego katalogu macierzystego. System wykorzystuje tę informację dla utrzymania wewnętrznej spójności katalogu.

Budowa atrybutu $Index_Root

Poniżej zamieszczono wydruk rekordu MFT katalogu Dir_One przedstawiający atrybut $Index_Root

<<Końcówka atrybutu $File_Name>>

00 00 00 10 00 00 00 00 07 03 44 00 69 00 72 00 ..........D.i.r.

5F 00 4F 00 6E 00 65 00 _.O.n.e.

<<Atrybut $Index_Root, kod typu 90. W nagłówku, zaznaczonym czcionką pogrubiną, rozpoznajemy nazwę strumienia atrybutu $130. Atrybut zawiera pozycję File_1.txt, również zaznaczoną czcionką pogrubioną.>>

90 00 00 00 B8 00 00 00 ........

00 04 18 00 00 00 01 00 98 00 00 00 20 00 00 00 ............ ...

24 00 49 00 33 00 30 00 30 00 00 00 01 00 00 00 $.I.3.0.0.......

00 10 00 00 08 00 00 00 10 00 00 00 88 00 00 00 ................

88 00 00 00 00 00 00 00 1C 00 00 00 00 00 01 00 ................

68 00 56 00 00 00 00 00 1B 00 00 00 00 00 01 00 h.V.............

18 62 25 BF 5C C0 BE 01 18 62 25 BF 5C C0 BE 01 .b%.\....b%.\...

10 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 ................

20 00 00 00 00 00 00 00 0A 03 46 00 69 00 6C 00 ..........F.i.l.

65 00 5F 00 31 00 2E 00 74 00 78 00 74 00 00 00 e._.1...t.x.t...

00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 00 ................

FF FF FF FF 82 79 47 11 00 00 00 00 00 00 00 00 .....yG.........

Blok danych atrybutu $Index_Root — nie mylić z atrybutem $Data — jest zawsze strumieniem ze zdefiniowaną nazwą. Nosi nazwę $I300. Blok danych atrybutu zawiera kopię atrybutu $File_Name pliku FILE_1.TXT.

Podkreślona liczba na początku nazwy pliku to numer kolejny MFT katalogu Dir_One, wykorzystywany przez system do sprawdzania wewnętrznej spójności. Jeśli plik ma nazwę długą, obydwa atrybuty — nazwa długa i nazwa krótka będą wpisane w rekordzie katalogu. Kopiowanie tych atrybutów z każdego pliku i podkatalogu powoduje niewielkie zwiększenie liczby zapisów/odczytów dysku, za to znacząco poprawia wydajność przeglądania katalogu.

Nierezydentne atrybuty $Index_Root i sortowanie struktury typu drzewo (B-Tree)

Dla niewielkich katalogów, takich jak w powyższym przykładzie, atrybut $Index_Root jest rezydentny, ponieważ nazwa pliku mieści się w pojedynczym rekordzie MFT. Jeśli katalog ma więcej niż pięć pozycji — mniej w przypadku plików o nazwach długich — system przenosi blok danych atrybutu $Index_Root na zewnątrz MFT na dysk. Zamiast stosowania długich ciągów jednostek alokacji, które mogą ulec fragmentacji, system wykorzystuje do przechowywania nierezydentnego bloku danych atrybutu $Index_Root bufory indeksowe o stałym rozmiarze 4 kB.

Zależnie od długości nazw plików każdy bufor 4-kilobajtowy może pomieścić około 20-40 pozycji. Poniższy wydruk przedstawia zawartość bufora indeksowego dla plików o nazwach 100.txt, 101.txt itd.

<<Początek bufora indeksowego nierezydentnej części atrybutu $Index_Root.>>

49 4E 44 58 28 00 09 00 88 6B 10 00 00 00 00 00 INDX(...k.......

00 00 00 00 00 00 00 00 28 00 00 00 B8 07 00 00 ........(.......

E8 0F 00 00 00 00 00 00 02 00 00 00 74 00 BE 01 ............t...

00 00 74 00 BE 01 00 00 00 00 00 00 00 00 00 00 ..t..............

<<Nazwa pliku. Pogrubioną czcionką zaznaczono numer kolejny MFT rekordu pliku. Podkreślono numer kolejny MFT katalogu macierzystego danego pliku.>>

1D 00 00 00 00 00 01 00 60 00 50 00 00 00 00 00 ........'.P.....

1B 00 00 00 00 00 01 00 CA 39 60 57 E9 BD BE 01 .........9'W....

42 C7 66 55 E9 BD BE 01 CA 39 60 57 E9 BD BE 01 B.fU.....9'W....

CA 39 60 57 E9 BD BE 01 10 00 00 00 00 00 00 00 .9'W............

0B 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ .......

07 03 31 00 30 00 30 00 2E 00 74 00 78 00 74 00 ..1.0.0...t.x.t.

<<kolejna nazwa pliku. Należy zwrócić uwagę, że ten plik został utworzony zaraz po pliku 100.txt, ponieważ ma następny numer kolejny MFT.>>

1E 00 00 00 00 00 01 00 60 00 50 00 00 00 00 00 ........'.P.....

1B 00 00 00 00 00 01 00 24 9C 62 57 E9 BD BE 01 ........$.bW....

42 C7 66 55 E9 BD BE 01 24 9C 62 57 E9 BD BE 01 B.fU....$.bw....

24 9C 62 57 E9 BD BE 01 10 00 00 00 00 00 00 00 $.bW............

0B 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ .......

07 03 31 00 30 00 31 00 2E 00 74 00 78 00 74 00 ..1.0.1...t.x.t.

Część rezydentna atrybutu $Index_Root zawiera wskaźniki do buforów indeksowych. Wskaźniki te są równoważne, jak gałęzie w strukturze drzewa. Rys. 13.5 przedstawia katalog w postaci drzewa. Przeszukiwanie drzewa nie wymaga dużego nakładu pracy ze strony systemu plików. Czy nazwa pliku jest leksykograficznie mniejsza od 120.txt? Jeśli tak, idź w lewo. W przeciwnym przypadku idź w prawo.

--> Rysunek 13.5. Rekord katalogu przedstawiający strukturę drzewa i dwa nierezydentne bufory indeksowe.[Author:E]

Directory Record — Rekord katalogu. Decyzja o przechodzeniu pomiędzy gałęziami drzewa nie musi być dwustanowa. Liczba indeksów w atrybucie $Index_Root rośnie wraz ze wzrostem liczby pozycji w katalogu. Kiedy bufor indeksowy zapełnia się, system kopiuje drugą połowę jego zawartości do nowego bufora i wpisuje pierwszą nazwę pliku w ciągu jednostek alokacji do atrybutu $Index_Root jako wskaźnik i indeks struktury typu drzewo (b-tree). Poniższy wydruk przedstawia rezydentną część atrybutu $Index_Root katalogu Dir_One.

<<Wyciąg z atrybutu $Index_Root przedstawia dwie gałęzie drzewa (b-tree), 0 i 120.txt (zaznaczona --> pogrubioną czcionką[Author:UP] ). $I300 jest nazwą atrybutu $Index_Root. Standardowy katalog ma tylko jeden atrybut $Index_Root, ale może mieć więcej.>>

24 00 49 00 33 00 30 00 30 00 00 00 01 00 00 00 $.I.3.0.0.......

00 10 00 00 08 00 00 00 10 00 00 00 F8 00 00 00 ................

F8 00 00 00 01 00 00 00 33 00 00 00 00 00 01 00 ........3.......

68 00 50 00 01 00 00 00 1C 00 00 00 00 00 01 00 h.P.............

FC D8 FC 70 EE BD BE 01 A2 A5 35 99 ED BD BE 01 ...p......5.....

FC D8 FC 70 EE BD BE 01 FC D8 FC 70 EE BD BE 01 ...p.......p....

10 00 00 00 00 00 00 00 09 00 00 00 00 00 00 00 ................

20 00 00 00 00 00 00 00 07 03 31 00 32 00 30 00 ..........1.2.0.

2E 00 74 00 78 00 74 00 00 00 00 00 00 00 00 00 ..t.x.t.........

48 00 00 00 00 00 01 00 68 00 50 00 01 00 00 00 H.......h.P.....

1C 00 00 00 00 00 01 00 16 91 8A 5B EF BD BE 01 ...........[....

A2 A5 35 99 ED BD BE 01 16 91 8A 5B EF BD BE 01 ..5........[....

16 91 8A 5B EF BD BE 01 10 00 00 00 00 00 00 00 ...[............

09 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ .......

Budowa indeksu wykorzystująca strukturę typu drzewo (b-tree) porządkuje się sama. Powiedzmy, że do katalogu Dir_One zostanie dodany plik o nazwie 1000.txt. Ponieważ leksykograficznie nazwa 1000.txt jest mniejsza niż 120.txt, zostanie umieszczona w pierwszym buforze indeksowym za nazwą 100.txt, a przed nazwą 101.txt. Jeśli do katalogu Dir_One wpisana zostanie duża liczba plików z serii 1000, spowoduje to utworzenie dodatkowych buforów z indeksami dodanymi do części rezydentnej atrybutu $Index_Root. Np. nowymi indeksami mogą być 1020.txt, 1040.txt i 120.txt.Wraz z dodawaniem plików do katalogu wzrasta również liczba buforów na dysku zawierających wskaźniki w atrybucie $Index_Root. W pewnym momencie wskaźniki przekraczają pojemność rekordu MFT. Wtedy system przenosi wskaźniki poza MFT do dwóch buforów INDX i zapisuje poza --> innym[Author:UP] zestawem wskaźników. Zasadniczo indeksuje ponownie drzewo bez żadnych dodatkowych zabiegów. Rys. 13.6 przedstawia widok nowej struktury b-tree. Proces może trwać w nieskończoność. Jeśli liczba nierezydentnych wskaźników do katalogów jest zbyt duża, by zmieścić się w 4-kilobajtowym buforze indeksowym, system tworzy nowy zestaw buforów i wpisuje do rekordu MFT jeszcze jeden wskaźnik.

--> Rysunek 13.6. Bardziej złożona struktura drzewa z indeksowaniem wtórnym[Author:E]

Oddzielne indeksowanie nazw krótkich i nazw długich

Nazwy długie powodują komplikacje takiego sposobu indeksowania. Atrybut $Index_Root sortuje nazwy plików alfanumerycznie bez rozróżniania na nazwy krótkie i nazwy długie. Na przykład mając trzy nazwy długie, takie jak: Twilight of the Gods.txt, Twilight Double-Header.txt oraz Twilight Zone.txt, w jednym katalogu, nazwy krótkie TWILIG~1, TWILIG~2 i TWILIG~3 po sortowaniu znajdą się na początku listy plików. Bardzo duża liczba plików mających nazwy długie zaczynające się od jednakowych ciągów znaków, jest przyczyną znacznego obniżenia się wydajności systemu poprzez wymuszanie sprawdzania wszystkich buforów indeksowych w poszukiwaniu nazw krótkich odpowiadających tym nazwom długim.

Wyłączenie możliwości tworzenia nazw plików w postaci 8.3

Problemy z wydajnością, których przyczyną są nazwy --> krótkie[Author:UP] , można usunąć poprzez pozbawienie użytkowników możliwości tworzenia takich nazw. Pozwoli to również zmniejszyć obszar dysku wykorzystywany do zapisywania buforów indeksowych. Można to zrobić wyłącznie w przypadku, kiedy nie ma klientów DOS/Win.x. Oto odpowiedni wpis do Rejestru:

Key: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem

Value: NTFSDisable8dot3NameCreation

Data: 0

$Index_Allocation i $Bitmap

System plików, czyniąc część atrybutu $Index_Root nierezydentnym, w celu poprawienia wydajności dodaje dwa atrybuty do rekordu katalogu. Jeden z nich to atrybut $Index_Allocation. Ten atrybut zawiera licznik całkowitej liczby buforów indeksowych wykorzystywanych przez katalog. (W rzeczywistości zapamiętuje liczbę bajtów, ale ponieważ bufor indeksowy ma stałą wielkość, jest to równoznaczne.) Przechowuje również odwzorowanie liczby wirtualnych jednostek alokacji (Virtual Cluster Number — VCN) w buforze na liczbę logicznych jednostek alokacji (Logical Cluster Number — LCN) położenia bufora.

Atrybut $Bitmap pomaga systemowi plików znaleźć konkretny bajt w pliku, zwiększając wydajność przeszukiwania plików z dostępem swobodnym (random-access files), takich jak bazy danych, pliki utworzone przez edytory tekstów lub programy do przetwarzania obrazów. Jeden z dodatkowych atrybutów nazwany jest $Bitmap. Zawiera odwzorowanie niewykorzystanego obszaru w buforach, więc system wie czy konieczny jest jeszcze jeden bufor bez przeszukiwania wszystkich pozycji. Obydwa atrybuty muszą być rezydentne w rekordzie katalogu. Oto wydruk:

<<Atrybut $Index_Allocation, kod typu A0. Liczby zaznaczone czcionką pogrubioną są odwzorowaniem LCN na VCN>>

A0 00 00 00 50 00 00 00 01 04 40 00 00 00 03 00 ....P.....@.....

00 00 00 00 00 00 00 00 27 00 00 00 00 00 00 00 ........'.......

48 00 00 00 00 00 00 00 00 50 00 00 00 00 00 00 H........P......

00 50 00 00 00 00 00 00 00 50 00 00 00 00 00 00 .P.......P......

24 00 49 00 33 00 30 00 11 0A 16 21 1E F1 2F 00 $.I.3.0....!../.

B0 00 00 00 28 00 00 00 00 04 18 00 00 00 04 00 ....(...........

08 00 00 00 20 00 00 00 24 00 49 00 33 00 30 00 .... ...$.I.3.0.

1F 00 00 00 00 00 00 00 ........

Należy pamiętać, że te dwa atrybuty istnieją tylko wtedy, kiedy blok danych atrybutu $Index_Root jest przeniesiony na dysk i są stosowane, aby poprawić wydajność systemu i zapewnić spójność danych.

Atrybuty katalogu — podsumowanie

Poniżej zamieszczona jest lista najważniejszych informacji dotyczących zawartości i budowy rekordu katalogu MFT:

W katalogach zapisane są indeksy atrybutów nazw plików i katalogów.
Nazwy krótkie i nazwy długie są indeksowane oddzielnie.
Każdy rekord pliku i katalogu zawiera pozycję wskazującą rekord MFT katalogu, w którym znajduje się jego indeks.
Rekordy katalogów zawierają niewielkie odwzorowania jednostek alokacji, przyspieszające szukanie pojedynczych bajtów w plikach o dostępie swobodnym.

Do sortowania nazw plików wykorzystuje się strukturę drzewa (b-tree), co znacznie poprawia wydajność przeszukiwania.
Rekord katalogu może ulec fragmentacji, zmuszając system plików do niezależnego przeglądania dysku w poszukiwaniu jakiegoś pliku.

Opis dodatkowych rekordów metadanych

Konieczny jest rzut oka na kilka dodatkowych rekordów metadanych. Są to: $MFT, $Bitmap, MFTMirr, $BadClus i $Volume.

$MFT i $Bitmap

MFT jest bazą danych zawierającą w sobie wszystkie informacje konieczne do korzystania z tej bazy. Nie są potrzebne żadne zewnętrzne słowniki danych. Oznacza to, że MFT sama jest plikiem i jako taka wymaga rekordu w MFT. To jest właśnie funkcja, którą spełnia rekord $MFT. Rekord $Bitmap, podobnie jak tablica FAT, zawiera odwzorowanie zajętych i niewykorzystanych jednostek alokacji danego dysku. Jednakże w odróżnieniu od FAT, gdzie jednostce alokacji odpowiadają 2 lub 4 bajty, w tym przypadku jednostce alokacji odpowiada jeden bit rekordu $Bitmap.

Rekord $MFT powinien być umieszczony w konkretnym miejscu, ponieważ program ładujący (secondary bootstrap loader) Ntldr musi być w stanie go znaleźć. Położenie MFT jest zapisane w sektorze startowym (boot sector). Oto najważniejsze właściwości rekordu $MFT:

--> $MFT zawiera wszystkie pliki konieczne do odczytania plików $MFT[Author:UP] .
W $MFT zapisana jest mapa bitowa opisująca budowę tablicy pliku. Poprawia to wydajność.
$MFT musi znajdować się w konkretnym położeniu wskazanym w sektorze startowym (boot sector), by program ładujący (secondary bootstrap loader) mógł go znaleźć.

$MFTMirr

W trakcie ponownego startu komputera po awarii systemu, program ładujący (bootstrap loader) musi być w stanie znaleźć pierwszy rekord MFT, aby załadować początkowe rekordy metadanych MFT i zainicjować system plików. Jeśli pierwszy rekord MFT jest uszkodzony lub niemożliwy do odczytania z jakiegokolwiek innego powodu, program ładujący (bootstrap loader) musi przedsięwziąć kroki w celu odtworzenia systemu plików. Z tego powodu najważniejsze rekordy metadanych są kopiowane w środku woluminu. Rekord metadanych $MFTMirr zawiera liczbę logicznych jednostek alokacji (Logical Cluster Number) pozostałych rekordów MFT.

Oto najważniejsze właściwości atrybutu $MFTMirr:

Kopia nie zawiera wszystkich rekordów MFT, lecz tylko najważniejsze rekordy metadanych.
Kopia jest zapisana w środku woluminu.
Program ładujący (secondary bootstrap loader) w razie potrzeby znajduje kopię na podstawie informacji zapisanych w sektorze startowym (boot sector).

$BadClus

Kiedy NTFS nie jest w stanie odczytać danych z jednostki alokacji, pierwszym działaniem, jakie podejmuje, jest oczekiwanie, aż sterownik SCSI udostępni sektor zapasowy. Jeśli w komputerze zainstalowane są dyski IDE lub w obszarze zapasowym na dysku nie ma już wolnych sektorów, NTFS przenosi dane do zapasowego sektora w dołączonym woluminie. Jednostka alokacji zawierająca sektor uszkodzony jest zaznaczona jako uszkodzona poprzez wpisanie LCN do bazy danych $BadClus. Każda z pozycji bazy danych ma postać strumienia danych ze zdefiniowaną nazwą. W istocie system przyporządkowuje jakiś plik do uszkodzonego sektora, aby inny plik nie mógł go użyć.

Oto najważniejsze informacje o atrybucie $BadClus:

--> NTFS znakuje uszkodzone jednostki alokacji niezależnie od rodzaju sterownika dysku.
Rekord $BadClus zawiera bazę danych uszkodzonych jednostek alokacji
Jeśli sektory rezerwowe nie są dostępne sprzętowo, NTFS stosuje własny sposób wykorzystania sektorów rezerwowych.[Author:PGon]

Rekord $Volume i atrybuty woluminu

Rekord $Volume przechowuje informacje o woluminie NTFS. Rekord ma ustaloną pozycję względem początku MFT, więc program ładujący (bootstrap loader) może go znaleźć. Rekord $Volume zwiera dwa specjalne atrybuty: $Volume_Name i $Volume_Information. Trzeci atrybut, $Volume_Version, wykorzystywany przez system plików NTFS4 został opuszczony w systemie NTFS5, a informacje w nim zawarte włączono do atrybutu $Volume_Information.

Poniższy wydruk przedstawia zawartość wyżej wymienionych atrybutów dla woluminu o nazwie Windows 2000 Volume.

<<Atrybut $Volume_Name, kod typu 60. --> Czcionką pogrubioną [Author:UP] przedstawiono 64 bajty bloku danych (32 znaki w kodzie Unicode).>>

60 00 00 00 40 00 00 00 00 00 18 00 00 00 04 00 ...@............

28 00 00 00 18 00 00 00 57 00 69 00 6E 00 64 00 (.......W.i.n.d.

6F 00 77 00 73 00 20 00 32 00 30 00 30 00 30 00 o.w.s. .2.0.0.0.

20 00 56 00 6F 00 6C 00 75 00 6D 00 65 00 20 00 .V.o.l.u.m.e. .

<<Atrybut $Volume_Information, kod typu 70. Pogrubioną czcionką zaznaczono informacje dotycząceNTFS5. Zawiera także znacznik błędu (dirty flag), obecnie nieustawiony, który uruchomiłby skanowanie dysku podczas startu systemu.>>

70 00 00 00 28 00 00 00 00 00 18 00 00 00 05 00 p...(...........

0C 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00 ................

03 00 00 00 00 00 00 00 ........

Na pierwszy rzut oka ciąg bajtów 00 00 00 03 nie wygląda jak numer wersji systemu plików NTFS5. W rzeczywistości na system plików NTFS5 wskazuje połączenie bajtu 03 z bloku danych i znacznika 05 00 z nagłówka atrybutu.

Oto najważniejsze informacje na temat rekordu $Volume i jego atrybutów:

Rekord $Volume jest tam, gdzie zapisana jest wersja systemu plików NTFS5.
Długość nazwy pliku jest ograniczona do 32 znaków.
Wolumin może mieć ustawiony znacznik błędu („dirty” flag ) wywołujący w trakcie uruchamiania systemu program Autochk.

Konwersja plików systemu FAT i FAT32 do systemu plików NTFS

Można dokonać konwersji partycji lub woluminu FAT oraz FAT32 do systemu NTFS. Operacja odwrotna jest niemożliwa. Jedynym sposobem przywrócenia stanu poprzedniego jest ponowne sformatowanie dysku i odtworzenie danych z taśmy. Przed konwersją koniecznie trzeba wykonać archiwizację systemu, ponieważ system może pracować niestabilnie lub nie wystartować ponownie.

Konwersji dokonuje się uruchamiając program Convert z wiersza poleceń. Składnia polecenia jest następująca:

convert volume_name /fs:ntfs

Można podać dysk, nazwę woluminu lub katalog dołączania (mount point). Jeśli podaje się oznaczenie literowe dysku, pojawia się zapytanie o nazwę woluminu, aby sprawdzić, czy wpisano prawidłowy dysk. Aby sprawdzić nazwę woluminu należy uruchomić program VOL. W celu efektywnego wykorzystania woluminu podczas konwersji domyślny rozmiar jednostki alokacji ustalono na 512 bajtów. Nie można zmienić później rozmiaru jednostki alokacji bez ponownego sformatowania woluminu.

System plików musi mieć wyłączność na dostęp do konwertowanych plików. Jeśli taka wyłączność nie jest zapewniona, system zapyta czy ma dokonać konwersji przy następnym uruchomieniu. Odpowiedź twierdząca spowoduje następujący wpis do Rejestru:

Key: HKLM\SYSTEM\CurrentControlSet\Control\SessionManagerValue: BootExecute

Data: autochk autoconv \??\e: /FS:ntfs

Pozycja \\??\e: jest połączeniem symbolicznym reprezentującym istniejący wolumin. Połączenie symboliczne pochodzi z obiektu Namespace (Object Namespace) i może być oglądane z użyciem WinObj. Więcej informacji zawarto w rozdziale 12.

Algorytm konwersji NTFS

Algorytm używany do konwersji woluminów FAT lub FAT32 do NTFS jest zaprojektowany tak, by zachowywał integralność FAT aż do zakończenia konwersji. Wszystkie pomocnicze dane tymczasowe są zapisywane w wolnym obszarze woluminu. Rekordy metadanych MFT również zapisywane są w wolnym obszarze dysku. Jedyną przyczyną awarii systemu przy ponownym uruchomieniu może być uszkodzenie sektora startowego. W tym wypadku należy uruchomić system z dyskietki startowej.

Do wykonania konwersji potrzeba dużo wolnego miejsca, którego rozmiar można oszacować w następujący sposób:

Pomnóż liczbę plików i katalogów w woluminie razy 1280.
Podziel rozmiar woluminu wyrażony w bajtach przez 100. Granica dolna wynosi 1.048.576, a górna 4.194.304. Dodaj wynik dzielenia do wyniku uzyskanego w punkcie 1.
Podziel rozmiar woluminu wyrażony w bajtach przez 803 i dodaj do wyniku uzyskanego w punkcie 2.
Dodaj 196.096 do wyniku uzyskanego w punkcie 3.

Poniżej przedstawiono obliczenia dla woluminu 4 GB zawierającego 100.000 plików:

100 000*1280 = 128 000 0004 GB* 1024 = 4096E6 / 100 = 409600004 096 000 + 128 000 000 = 132 096 0004096E6 / 803 = 5 100 871 + 132 096 000 = 137 196 871137 196 871 + 196 096 = 137 392 967

Do konwersji tego woluminu konieczne jest około 134 MB wolnego obszaru, co stanowi mniej więcej 5% obszaru całkowitego.

Najważniejsze informacje

Dokonując konwersji systemu plików FAT i FAT32 do systemu NTFS należy pamiętać o tym, że:

Konwersja zachowuje zawartość woluminu.

Nie wolno dokonywać konwersji „zatłoczonych” woluminów. Jeśli program konwertujący nie znajdzie ciągłego obszaru o wystarczającym rozmiarze, może dojść do fragmentacji MFT. Ma to niekorzystny wpływ na wydajność systemu.

Narzędzia do defragmentacji nie naprawiają MFT.

Domyślny rozmiar jednostki alokacji dla celów konwersji wynosi 512 bajtów i nie może zostać zmieniony.

Śledzenie połączeń rozproszonych (Distributed Link Tracking)

Spędzającym godziny, dni, a nawet tygodnie na planowaniu przenoszenia danych, poświęcającym ten czas na uzgodnienia z użytkownikami, których połączenia do plików są zagrzebane głęboko w strukturze katalogu w udziałach (share point), Windows 2000 przyniesie ulgę w postaci usługi śledzenia połączeń (Link Tracking Service — LTS). Ta usługa zapamiętuje położenie pliku źródłowego dla skrótów (shortcuts) i aplikacji wykorzystujących mechanizm OLE. Przykładem może być dokument Word zawierający połączenie OLE do arkusza kalkulacyjnego Excel. Jeśli arkusz kalkulacyjny zostanie przeniesiony, dokument osadzony nie jest w stanie go znaleźć. Przy użyciu usługi śledzenia połączeń plik znajdowany jest automatycznie, nawet jeśli zostanie przeniesiony do innego serwera w domenie.

Skrót lub aplikacje wykorzystujące mechanizm OLE, które tworzą połączenia do innych plików są nazywane klientami połączenia (link client). Plik docelowy dla połączenia jest nazywany źródłem połączenia (link source). W przypadku Windows NT4 i Windows 9x, jeśli klient połączenia nie może znaleźć źródła, Eksplorator znajduje oparcie w nieporęcznym algorytmie przeszukiwania. Zasadniczo Eksplorator zachowuje się jak suseł, który zgubił marchewkę: patrzy w dół, patrzy do góry, rozgląda się dookoła, a potem rezygnuje i idzie po następną marchewkę.

Sposób poszukiwania jest następujący:

Procedura 13.2. Sposób poszukiwania połączeń zastosowany w systemie Windows NT

Popatrz cztery poziomy w dół.
Przesuń się w górę o jeden i popatrz cztery poziomy w dół, do wszystkich katalogów dostępnych z tego położenia.
Przejdź do pulpitu i popatrz w dół cztery poziomy.
Przechodź do katalogu głównego każdego z dysków i popatrz w dół cztery poziomy.
Powtarzaj, bez ograniczenia do czterech poziomów, tak długo, jak pozwoli na to aplikacja — klient połączenia lub użytkownik.

Usługa LTS eliminuje takie poszukiwania. Tworzy w lokalnym komputerze bazę danych wszystkich plików źródłowych. Jeśli plik zostaje przeniesiony, baza danych jest aktualizowana i połączenie może być naprawione. Usługa LTS tworzy również w Active Directory centralną bazę danych o plikach źródłowych, które są przeniesione. Pozwala to na odtworzenie połączenia, nawet jeśli plik źródłowy został przeniesiony do innego serwera lub zmieniła się nazwa udziału (shared name).

Opis działania usługi śledzenia połączeń

LTS jest aplikacją typu klient/serwer. Klient LTS, TRKWKS, działa we wszystkich serwerach i stacjach roboczych Windows 2000. Serwer LTS, TRKSVR, działa w kontrolerze domeny. Klient LTS jest odpowiedzialny za aktualizację lokalnej bazy danych śledzenia po przeniesieniu źródła połączenia (link source). Informuje również serwer LTS, który zapisuje przeniesienie w kontenerze ObjectMoveTable funkcji Active Directory, którego DN jest następujący: cn=FileLinks, cn=System, dc=domain_dns_name, dc=dns_root_name. Aby można było oglądać go używając konsoli DSA, musi być wybrana opcja Zaawansowane (Advanced Features) w menu Podgląd (VIEW).

Jeśli źródło połączenia zostało przeniesione w inne miejsce w tym samym komputerze i jest dostępne przez ten sam udział (shared point), to LTS serwer nie jest konieczny. Lokalna baza danych jest aktualizowana po przeniesieniu przez klienta LTS. Kiedy klient połączenia próbuje znaleźć źródło połączenia, klient LTS znajduje w bazie danych nowe połączenie i aktualizuje klienta połączenia.

Jeśli źródło połączenia przeniesie się do innego udziału w tym samym komputerze lub do innego komputera w tej samej domenie, klient LTS przekazuje nowe połączenie serwerowi LTS. Kiedy klient połączenia próbuje otworzyć plik źródłowy, klient LTS kontaktuje się w imieniu aplikacji z serwerem LTS i prosi o znalezienie pliku. Serwer LTS przeszukuje Active Directory, odczytuje informacje o nowym położeniu i przekazuje te dane do klienta LTS, który z kolei aktualizuje klienta połączenia.

Wskazówka dotycząca Rejestru

--> Informacje dotyczące LTS znajdujące się w Rejestrze są zapamiętane [Author:UP] w HKLM|System|CurrentControlSet|Services jako TrkSvr i TrkWks. Wartości zapisane są w postaci binarnej, więc nie poleca się dokonywania wpisów do Rejestru.

Identyfikacja plików źródłowych

Zarówno serwer, jak i klient LTS muszą jednoznacznie rozpoznawać pliki źródłowe w skali całej korporacji. Jest to możliwe dzięki jednoznacznemu identyfikatorowi globalnemu (Globally Unique Identifier — GUID). GUID jest to 16-bajtowa (128-bitowa) struktura tworzona przez system i związana z plikiem źródłowym połączenia. Algorytm tworzący GUID łączy czas systemowy i adres MAC karty sieciowej, co gwarantuje niepowtarzalność identyfikatora. GUID zawiera:

4 bajty. time_low

2 bajty. time_mid

2 bajty. time_hi+version

1 bajt. clock_hi+variant

1 bajt. clock_low

6 bajtów. Adres MAC karty sieciowej komputera, z którego pochodzi plik źródłowy.

Plikowi lub katalogowi przyporządkowuje się GUID, kiedy staje się źródłem połączenia (link source). Dokonuje się tego poprzez dodanie nowego atrybutu $Object_ID, w którym zapisuje się GUID przyporządkowany do źródła połączenia. Ten GUID jest tworzony dla woluminu głównego, a jego wartość jest pierwsza z szeregu pozostałych GUID. Pozwala to systemowi plików i Active Directory na wskazywanie atrybutu przez jego źródło.

Wykorzystanie GUID do śledzenia użytkownikówInteresującym skutkiem ubocznym stosowania GUID jako indeksu jest prezentowanie w bazie danych adresów MAC każdego, kto tworzy połączenie. Znając korelację pomiędzy adresami MAC i właścicielami, można określić z kim trzeba się skontaktować w przypadku utraty połączenia po przeniesieniu danych.

Opis działania usługi śledzenia połączeń

Poniżej przedstawiono przykład wykorzystywania przez usługę LTS atrybutu $Object_ID do śledzenia pliku. W przykładzie tym został utworzony skrót. Skrót jest plikiem LNK, wskazującym na plik docelowy. Posługując się nazewnictwem OLE skrót jest klientem połączenia, plik docelowy jest źródłem połączenia. Procedura jest następująca:

Procedura 13.3 Sprawdzenie działania usługi śledzenia pliku

W woluminie NTFS5 utwórz plik o nazwie WHEREAMI.TXT.Utwórz skrót do tego pliku na pulpicie. System doda atrybut $Object_ID do rekordu pliku. Oto wydruk:

<<Plik o nazwie WhereAmI.txt>>20000000 00000000 0C035700 68006500 ..........W.h.e.

72006500 41006D00 49002E00 74007800 r.e.A.m.I...t.x.

74000000 00000000 t.......

<<Atrybut $Object_ID, kod typu 40, dodany po utworzeniu skrótu. GUID zaznaczono pogrubioną czcionką.>>

40000000 28000000 t.......@...(...

00000000 00000300 10000000 18000000 ................

C2EB101E F232D311 A77A00C0 4F536A4D .....2...z..OSjm

80000000 30000000 00001800 00000100 ....0...........

18000000 18000000 57686572 65206469 ........Where di

64207468 65206669 6C652067 6F3F0D0A d the file go?..

System wpisuje również dane do nowego rekordu metadanych MFT o nazwie $ObjID. Ten rekord korzysta z naturalnej zdolności katalogów NTFS do budowania indeksu rekordów MFT, mających atrybut $Object_ID. Poniższy wydruk przedstawia pozycje indeksu dla kilku plików źródłowych.

<<Atrybut $Index_Root rekordu $ObjID>>

90000000 00010000 00021800 00000200 ................

E0000000 20000000 24004F00 00000000 .... ...$.0.....

00000000 13000000 00100000 08000000 ................

10000000 D0000000 DOOOOOOO OOOOOOOO ................

20003800 00000000 58001000 00000000 .8.....X........

<<GUID utworzony przez pierwsze połączenie.

C2EB101E F232D311 A77A00C0 4F56A4D .....2...z..OsjM

<<Pierwszy indeks. Podkreślona liczba na początku pliku jest numerem kolejnym rekordu MFT pliku, który zawiera atrybut $Object_ID. Końcowa część każdej pozycji zawiera identyfikator GUID następnej. Młodszy bajt (podkreślony) jest zwiększany o jeden.>>

21000000 00000100 00000000 00000000 !...............

00000000 00000000 C2EB101E F232D311 .............2..

A77A00C0 4F536A4D 00000000 00000000 .z..OsjM........

00000000 00000000 20003800 00000000 ........ .8.....

58001000 00000000 C3EB101E F232D311 X............2..

A77A00C0 4F536A4D

<<Następny indeks. Numer kolejny wskazuje, że plik znajduje się pięć rekordów wyżej niż pierwszy indeks. Identyfikator GUID wzięty z ostatniej pozycji. Następny GUID jest przygotowany.>>

26000000 00000100 .z..OsjM&.......

00000000 00000000 00000000 00000000 ................

C3EB101E F232D311 A77A00C0 4F536A4D .....2...z..OsjM

00000000 00000000 00000000 00000000 ................

20003800 00000000 58001000 00000000 .8.....X........

C4EB101E F232D311 A77A00C0 4F536A4D .....2...z..OsjM

Trzeba przypomnieć, że plik będący źródłem połączenia otrzymuje identyfikator GUID z bazy danych $ObjID. Ten identyfikator nie jest utworzony przy użyciu standardowego algorytmu obliczania GUID.

Klient połączenia zapamiętuje GUID źródła połączenia razem z informacją o samym połączeniu. Informacja taka jest zapisana w atrybucie $Data rekordu pliku LNK. Poniższy fragment wydruku przedstawia część atrybutu $Data odnoszącą się do śledzenia połączenia.

<<Nazwa klienta połączenia (link client)>>

1C015300 68006F00 72007400 63007500 ..S.h.o.r.t.c.u.

74002000 74006F00 20005700 68006500 t. .t.o. .W.h.e.

72006500 41006D00 49002E00 74007800 r.e.A.m.I...t.x.

74002E00 6C006E00 6B000000 00000000 t...l.n.k.......

<<Elementy ścieżki do pliku źródłowego>>

00446972 5F4F6E65 00001700 31000000 .Dir_One....1...

0000E326 6A941000 5375625F 4F6E6500 ...&j...Sub_One.

001C0032 00180000 00E3266B 94200057 ...2......&k. .W

68657265 416D492E 74787400 00000065 hereAmI.txt....e

<<Pełna ścieżka dostępu do pliku źródłowego, zawierająca dane o lokalizacji dla dysku mapowanego>>5C686F75 2D77326B 702D30315C707562 \hou-w2kp-01\pub

6C696300 463A0044 69725F4F 6E655C53 lic.F:.Dir_One\S

75625F4F 6E655C57 68657265 416D492E ub_One\WhereAmI.

74787400 1C004C00 6F006300 61007400 txt...L.o.c.a.t.

69006F00 6E003A00 20004600 3A005C00 i.o.n.:.F.:.\.

44006900 72005F00 4F006E00 65005C00 D.i.r._.O.n.e.\.

53007500 62005F00 4F006E00 65001200 S.u.b._O.n.e...

46003A00 5C004400 69007200 5F004F00 F.:.\.D.i.r._.O.

65006500 5C005300 75006200 5F004F00 n.e.\.S.u.b._.O.

6E006500 60000000 030000A0 58000000 n.e.'.......X...

<<Nazwa komputera macierzystego pliku źródłowego>>

00000000 686F752D 77326B70 2D303100 ....hou-w2kp-01.

<<Identyfikator GUID pliku źródłowego (podany dwukrotnie)>>

1CBFBADE 8931D311 98B00800 09C0E241 .....1.........A

--> A więc scena jest przygotowana[Author:E] . Skrót — klient połączenia (link client) — zna identyfikator GUID źródła połączenia (link source) i lokalizację pliku źródłowego. Teraz nastąpi test usługi LTS.

Przenieś plik źródłowy połączenia do innego katalogu na tym samym woluminie. Upewnij się, czy ten katalog jest widzialny z tego skrótu. W tym punkcie testuje się tylko klienta LTS. Ponieważ plik zmienił tylko swój katalog, jego rekord MFT nie został przeniesiony, więc odpowiadający mu indeks z bazy danych $ObjID nie zmieni się. Jednakże ścieżka dostępu do pliku źródłowego połączenia (link source file) zapisana w pliku LNK jest nieprawidłowa.
Spróbuj otworzyć plik wykorzystując skrót. Pojawia się ikona poszukiwania, odciągając uwagę użytkownika, podczas gdy system plików wysyła oszalałe sygnały do klienta LTS. Klient LTS przeszukuje bazę danych $ObjID i znajduje rekord MFT odpowiadający źródłu połączenia. Przeszukuje ten rekord i znajduje nowy katalog. Następnie przekazuje systemowi plików, by zaktualizować informacje w rekordzie klienta połączenia i plik zostaje otwarty.
Taka kolejność działań staje się bardziej skomplikowana, jeśli plik zostanie przeniesiony do innego komputera. W tym przypadku klient LTS informuje serwer LTS znajdujący się w kontrolerze domeny, że źródło połączenia (link source) zostało przeniesione. Serwer LTS aktualizuje Active Directory.
Kiedy klient połączenia (link client) próbuje otworzyć plik źródłowy, klient LTS wykonuje wywołanie sieciowe serwera LTS, podając mu identyfikator GUID pliku źródłowego połączenia.
Serwer LTS odsyła informację w tabeli połączenia (link table) dla podanego identyfikatora GUID.
Klient LTS przekazuje tę informację do systemu plików, który aktualizuje dane o lokalizacji w pliku LNK. Plik zostaje otworzony.
Jeśli klient LTS nie może zlokalizować źródła połączenia, przechodzi do zwykłego algorytmu i podaje użytkownikowi najlepsze rozwiązanie. Zwykle jest to błędne rozwiązanie. Użytkownik może wybrać skasowanie połączenia i zbudowania ponownie. Niemal pewna jest interwencja administratora.

Śledzenie połączeń (link tracking) — podsumowanie

Oto najważniejsze informacje dotyczące usługi śledzenia połączeń (link tracking):

Usługa LTS dotyczy tylko woluminów NTFS5, których komputery macierzyste pracują pod kontrolą sytemu Windows 2000.

Śledzenie połączeń rozproszonych (distributed link tracking) działa niezawodnie tylko w obrębie domeny. Zdarzają się „przypadki sukcesu” dotyczące komputerów z różnych domen lub grup roboczych, ale niezawodność konieczna do stosowania tej usługi przez użytkowników występuje tylko wtedy, kiedy komputery należą do tej samej domeny.

Kiedy klient LTS znajduje nową ścieżkę sieciową, aktualizowana jest tylko pozycja Target dla połączenia, Start In pozostaje bez zmian. To może być przyczyną problemów z aplikacjami DOS, wykorzystującymi Start In do znajdowania nakładek (overlay), i dla aplikacji Win16, które muszą znaleźć pliki INI.

Po skopiowaniu pliku atrybut $Object_ID i związany z nim atrybut GUID pozostają z plikiem pierwotnym.

Kiedy odtwarza się z taśmy plik, który jest plikiem źródłowym połączenia, odtwarzany jest również atrybut $Object_ID. Po odtworzeniu do innego położenia otrzymuje się w tej samej domenie dwa pliki mające jednakowe nazwy i ten sam identyfikator GUID, co może być przyczyną problemów, jeśli pojawią się połączenia do tych plików i usługa śledzenia straci orientację. Należy zachować szczególną ostrożność przy odtwarzaniu plików.

Dynamiczny wskaźnik lokalizacji danych (Reparse Point)

Dynamiczne wskaźniki lokalizacji (reparse points) przeadresowują wskaźniki do woluminów na innych dyskach twardych, CD-ROM-ach, lub do plików w bibliotekach zapisanych na taśmie. Wykorzystując te wskaźniki, można przedstawić cały dysk jako folder, bez potrzeby wykorzystywania dodatkowych nazw dysku i udziałów (share points). Są również nazywane katalogami dołączania (mount point). Aplikacja, napotykając na katalog dołączania, przeskakuje do innego woluminu i działa dalej tak, jakby nic się nie stało.Dynamiczne wskaźniki lokalizacji (reparse points) można napotkać sprawdzając folder \WINNT\Sysvol\Sysvol\<domain_name> w kontrolerze domeny. Udział (share point) o nazwie SYSVOL znajduje się w drugim folderze Sysvol. Zawartość tego drugiego folderu Sysvol jest w rzeczywistości katalogiem dołączania dla folderów \WINNT\Sysvol\Domain. Więcej szczegółów zawarto w rozdziale 17.

Firma Microsoft stosuje dynamiczne wskaźniki lokalizacji (reparse points) umożliwiając przechowywanie danych „prawie on-line” za pomocą usługi zdalnego przechowywania danych (Remote Storage Services — RSS). W tym przypadku plik fizycznie może znajdować się na taśmie, podczas gdy wskaźnik obsługuje interfejs pomiędzy lokalnym systemem plików a taśmą. Rysunek 13. 7 przedstawia wygląd katalogu zawierającego foldery i pliki ze wskaźnikami lokalizacji (reparse points) i rekordu MFT.

--> Brak rysunku 13.7 [Author:E] Rysunek 13.7. Przedstawienie katalogów dołączania (mount points) i plików zdalnego przechowywania wykorzystujących dynamiczne wskaźniki lokalizacji danych (reparse points).

--> Directory Atrybut $Index_Root zawiera dane dotyczące następujących rekordów: BidFile.bmp, Database.mdb, MountPoint, Sub_Dir

Basset.bmp Atrybut $Data zawiera 3MB danych binarnych zawierających obrazek psa basseta, którego właścicielem jest użytkownik.

MountPoint Rekord katalogu z pustym atrybutem $Index_Root. Atrybut $Reparse zawiera połączenie symboliczne do systemu plików na drugim dysku.

Sub_Dir Atrybut $Index_Root zawiera dane dotyczące następujących rekordów: DeadHead.wav.

DeadHead.wav Atrybut $Data zawiera informacje o pliku. Atrybut $Reparse zawiera wskaźnik do zdalnej biblioteki na taśmie. Biblioteka na taśmie zawiera plik o rozmiarze 2358 MB.

Ale to zupełnie inaczej wygląda w oryginale, to jest nieczytelne ![Author:E]

Opis działania katalogów dołączania

Dynamiczne wskaźniki lokalizacji (reparse points) są zależne od dwóch nowych pozycji w tablicy MFT:

Atrybut $Reparse_Point. Ten atrybut zawiera informacje o zdalnym systemie plików. Jeśli jest to dyskowy system plików, to atrybut zawiera informacje o połączeniu symbolicznym z Object Namespace. Object Namespace opisano w poprzednim rozdziale. Odwołanie do pliku (handle) \Device w Object Namespace zawiera listę urządzeń wirtualnych obsługiwanych przez Egzekutora (Executive) Windows 2000. Nazwa połączenia symbolicznego zawarta w $Reparse_Point wskazuje na system istniejący w urządzeniu wirtualnym przedstawiającym CD-ROM dołączony do katalogu. Zawartość Object Namespace można oglądać za pomocą WINOBJ z Platform SDK lub www.sysinternals.com.
Baza danych menedżera dołączania (Mount Manager Database). NTFS utrzymuje indeks rekordów MFT zawierających atrybuty $Reparse_Point. Ten indeks jest zapisany w nowym rekordzie metadanych o nazwie $Reparse. System zakłada również specjalną bazę danych $MountMgrRemoteDatabase, która jest strumieniem $Data ze zdefiniowaną nazwą (named stream) w katalogu głównym („Root” directory) — to jest rekordem metadanych $\. Baza danych zawiera informacje o zdalnym systemie plików, włącznie z jego lokalizacją i kodem filtrującym (file system filter code), dostęp do tego systemu. Można wyspecyfikować do 16 kB dla tego filtru.

Najlepszym sposobem przyjrzenia się działaniu omówionych powyżej elementów jest prześledzenie krok po kroku przykładowej procedury tworzenia katalogu dołączania. Krótko mówiąc, w celu dołączenia woluminu do pustego foldera na innym woluminie, wykorzystuje się konsolę Zarządzanie komputerem (Computer Management). Wolumin macierzysty, tzn. wolumin zawierający katalog dołączania, musi być sformatowany w systemie NTFS. Jako katalog dołączany może wystąpić inny dysk twardy, napędy Zip lub Jaz, a nawet CD-ROM lub DVD.Katalog dołączany może być sformatowany w dowolnym systemie plików obsługiwanym przez Windows 2000, takim jak FAT, FAT32, NTFS, CDFS lub UDFS. Może zawierać pliki skompresowane i zaszyfrowane. Dla zabawy przyjęto przykład dołączania napędu CD-ROM.Procedura 13.4 Tworzenie katalogu dołączania z wykorzystaniem konsoli Zarządzanie dyskiem (Disk Mnagement)

W woluminie NTFS, w dowolnym podkatalogu, utwórz folder o nazwie Mount, który będzie spełniał rolę katalogu dołączania. Folder musi być pusty, w przeciwnym przypadku nie może służyć jako katalog dołączania. Po przekształceniu foldera w katalog dołączania, pliki i katalogi dodane do katalogu dołączania, są dołączone do dołączanego woluminu.
Otwórz konsolę Zarządzanie komputerem (Computer Management), wybierając START|PROGRAMS|ADMINISTRATIVE TOOLS|COMPUTER MANAGEMENT.
Przejdź do Storage|Disk Management. Rysunek 13.8 przedstawia plan dysku.

Rysunek 13.8. Konsola Disk Management (Zarządzanie dyskiem) przedstawiająca plan dysku.

Kliknij prawym klawiszem myszy na pasku przedstawiającym napęd CD-ROM i z menu wybierz opcję CHANGE DRIVE LETTER AND PATH (Zmień literę dysku i ścieżkę dostępu). Pojawi się okno Drive Letter and Paths (Litera dysku i ścieżki dostępu). Zobacz rysunek 13.9.

Rysunek 13.9. Okno Drive Letter and Paths (Litera dysku i ścieżki dostępu).

Naciśnij przycisk Dodaj (Add). Otworzy się okno Dodaj nowe litery dysku lub nową ścieżkę dostępu (Add new Drive Letter or Path).

Wybierz opcję Montuj wolumin w pustym folderze obsługującym ścieżki do napędów (Mount this volume at an empty folder which supports drive paths) i naciśnij przycisk Przeglądaj (Browse). Pojawi się okno Poszukiwanie ścieżki dostępu do napędu (Browse for Drive Path).
Przejdź do woluminu NTFS, do którego ma być dołączony CD-ROM. W niniejszym przykładzie jest to folder o nazwie Mount. Można również wybrać tworzenie nowego folderu. Dozwolone są nazwy długie.
Potwierdź nowy folder naciskając OK i zamknij okno.
Aby dołączyć napęd, w oknie Dodaj nową literę dysku lub ścieżkę dostępu (Add New Drive Letter or Path) naciśnij OK. Konsola Zarządzanie dyskiem (Disk Management) nie pokaże, że wolumin jest dołączony do innego woluminu.
Kliknij prawym klawiszem myszy na pasku przedstawiającym wolumin NTFS, zawierającym katalog dołączania (mount point) — w niniejszym przykładzie napęd F i wybierz z menu opcję Eksplorator. Otworzy się okno Eksploratora. (Uwaga: Jeśli dołączony wolumin nie ma przypisanej litery, nie ma bezpośredniego dostępu do pliku z wykorzystaniem Eksploratora. Konieczne jest otwieranie folderu macierzystego z woluminu mającego oznaczenie literowe).
Przejdź do folderu zawierającego katalog dołączania (mount point). Ikona dla folderu dołączania zmienia się w ikonę powiązaną z dyskiem znajdującym się w napędzie CD-ROM.
Kliknij prawym klawiszem myszy na woluminie dołączonym i wybierz z menu opcję Właściwości (Properties). Pojawi się okno Właściwości (Properties) dla tego woluminu. Zamiast pokazywania właściwości napędu CD, okno pokazuje tylko, że jest to wolumin dołączony (Mounted Volume). Aby zobaczyć właściwości woluminu dołączonego, naciśnij przycisk Właściwości (Properties) woluminu dołączonego.
Zamknij okno Właściwości (Properties). Kliknij dwukrotnie na ikonie katalogu dołączania lub rozszerz strukturę katalogów w Eksploratorze, żeby zobaczyć zawartość. Napęd CD jest otwarty do przeglądania. Program AUTORUN nie działa w katalogach dołączania.

Opis rekordów MFT po utworzeniu katalogów dołączania (mount point)

Rekord MFT folderu będącego katalogiem dołączania (mount point) ma atrybut $Reparse_Point, kod typu C0. Atrybut $Index_Root pozostawiono pusty. Katalog dołączania (mount point) nie może być zwykłym katalogiem. Oto wydruk katalogu Mount przedstawiający atrybut $Reparse_Point.

<<nazwa katalogu>>

00000010 00000000 05034D00 6F007500 ..........M.o.u.

6E007400 00000000

<<Atrybut $Index_Root - w przypadku katalogów dołączania (mount points) zawsze pusty.

90000000 50000000 n.t.........P...

00041800 00000100 30000000 20000000 ........0... ...

24004900 33003000 30000000 01000000 $.I.3.0.........

00100000 08000000 10000000 20000000 ............ ...

20000000 00000000 00000000 00000000 ................

10000000 02000000

<<Atrybut $Reparse_Point przedstawiający połączenie symboliczne (symbolic link) do nazwy woluminu.>>

C0000000 90000000 ................

00000000 00004000 76000000 18000000 ........v.......

030000A0 6E000000 00006200 64000000 ....n.....b.d...

5C003F00 3F005C00 56006F00 6C007500 \.??.\.V.o.l.u.

6D006500 7B003100 30003500 35003900 m.e.{.1.0.5.5.9.

65006300 32002D00 32003700 32006200 e.c.2.-.2.7.2.b.

2D003100 31006400 33006400 39003800 -.1.1.d.3.-.9.8.

61003300 2D003800 30003600 64003600 a.3.-.8.0.6.d.6.

31003700 32003600 39003600 66007D00 1.7.2.6.9.6.f.}.

5C000000 00000000 FFFFFFFF 82794711 \............yG.

Ważną częścią tego wydruku są informacje o połączeniu symbolicznym (symbolic link) zapisane w atrybucie $Reparse_Point. Dane dotyczące połączenia symbolicznego zawsze zaczynają się ciągiem znaków 030000A0. Blok danych określa nazwę połączenia symbolicznego (symbolic link) wpisaną do Object Namespace. W powyższym przykładzie połączenie symboliczne (symbolic link) nosi nazwę \??\Volume{10559ec2-272b-11d3-98a3-806d6172696f}\.

Oprócz atrybutu $Reparse w samym rekordzie katalogu, system dokonuje również wpisu do bazy danych $MountMgrRemoteDatabase. Ta baza danych jest zapisana jako strumień danych ze zdefiniowaną nazwą (named data stream) w „głównym” rekordzie metadanych , $\. Rekord $\ nie zawiera strumieni $Data bez nazwy (unnamed stream), więc wpisując do niego strumień danych ze zdefiniowaną nazwą (named data stream) skutecznie ukrywa się bazę danych $MountMgrRemoteDatabase przed resztą systemu. W bazie danych $MountMgrRemoteDatabase zapisane są nazwy połączeń symbolicznych (symbolic links) wykorzystywanych przez dynamiczne wskaźniki lokalizacji (reparse points) woluminu razem z ich danymi zapisanymi w Object Namespace oraz dodatkowymi informacjami o typie urządzenia. Fragment wydruku w zapisie szesnastkowym wygląda następująco:

$MountMgrRemoteDatabase..\??\Volume{10559ec2-272b-11d3-98a3-806d6172696f}\??SCSI#CdRom&Ven_SONY&Prod_CD-ROM_CDU-76S&Rev_11c#

3&1b3c1513&0&050#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

W powyższym przykładzie katalog dołączony to napęd CD-ROM SCSI. Jeśli wolumin jest na dysku twardym, pozycja ta dotyczy sterownika LDM, DMIO. Dane te mówią systemowi, który filtr systemu plików jest potrzebny do czytania z woluminu dołączonego. Atrybut $Reparse_Point może być zaimplementowany przez zewnętrznego dostawcę oprogramowania, który może wyszczególnić w bazie danych do 16 kB programu obsługi (handling code), działającego jak filtr systemu plików.System wpisuje także indeks do rekordu metadanych $Reparse. Poniżej przedstawiono wydruk rekordu $Reparse z trzema indeksami.

<<Końcowa część atrybutu nazwa pliku.>>

26000020 00000000 08032400 52006500 &.. ......$.R.e.

70006100 72007300 65000000 00000000 p.a.r.s.e.......

Atrybut $Index_Root zawierający indeksy rekordów ze wskaźnikami lokalizacji danych (reparse points).>>

90000000 B0000000 00021800 00000200 ................

90000000 20000000 24005200 00000000 .... ...$.R.....

00000000 13000000 00100000 08000000 ................

10000000 80000000 80000000 00000000 ................

<<Pozycje zaczynające się od 1C są indeksami. Liczby podkreślone to numer kolejny MFT wskazywanych rekordów.>>

1C000000 00000000 20000C00 00000000 ........ .......

030000A0 20000000 00000100 00000000 .... ...........

1C000000 00000000 20000C00 00000000 ........ .......

030000A0 21000000 00000100 00000000 ....!...........

1C000000 00000000 20000C00 00000000 ........ .......

030000A0 26000000 00000100 00000000 ....&...........

Wykorzystanie programu narzędziowego Linkd do dołączania folderów

Proces dołączania woluminu opisany w poprzednim paragrafie jest ograniczony do dołączania całego woluminu do danego katalogu dołączania (mount point). Windows 2000 Resource Kit zawiera program o nazwie Linkd, który można wykorzystać do dołączania dowolnego folderu lokalnego do folderu pustego. Składnia polecenia jest następująca: linkd <empty_folder> <source_folder>.

Przykładowo, aby dołączyć folder C:\WINNT do pustego folderu D:\TEST_DIR, należy wpisać:

linkd d:\test_dir c:\winnt

Nie można wykorzystać polecenia Linkd do dołączania foldera na dysku sieciowym. Skasowanie foldera kasuje tylko połączenie. Ikony folderów nie pokazują specjalnej ikony dołączonej (mounted icon), tak jak te wykorzystywane przez zwyczajne katalogi dołączania woluminów.Wskaźniki lokalizacji danych tworzone przez usługę Remote Storage ServiceWindows 2000 stosuje także wskaźniki lokalizacji danych (reparse points) jako wskaźniki do plików dostępnych w trybie offline, wykorzystując jedną z możliwości usługi zdalnego przechowywania danych (Remote Storage Service — RSS) — przechowywanie hierarchiczne. Szczegółowy opis usługi RSS zamieszczony jest w paragrafie --> „Usługi zdalnego przechowywania”[Author:PGon] w dalszej części tego rozdziału. Kiedy plik jest przeniesiony na taśmę, z punktu widzenia MFT atrybut $Data pozostaje bez zmian. System po prostu dodaje atrybut $Reparse zawierający informacje o tym, gdzie znajduje się zdalny atrybut $Data.

Poniżej zamieszczony jest wydruk pliku BIGFILE2.TXT, dostępnego w trybie offline. Zawartość atrybutu $Reparse dla pliku zdalnego jest nieco bardziej złożona, niż w przypadku katalogu dołączania (mount point). System musi zachować lokalizację biblioteki na taśmie, dokładne położenie danego pliku w tej bibliotece oraz informacje o samej bibliotece.

<<nazwa pliku>>0C036200 69006700 66006900 6C006500 ..b.i.g.f.i.l.e.32002E00 74007800 74002000 6F006600 2...t.x.t. .o.f.<<Nagłówek zdalnego atrybutu $Data>>

80000000 50000000 01000000 00800400 ....P...........

00000000 00000000 5F070000 00000000 ........_.......

48000400 00000000 00C00E00 00000000 H...............

0FB40E00 00000000 00000000 00000000 ................

00000000 00000000 02600700 88294080 .........'...)@.

<<Atrybut $Reparse_Point zawierający informacje dotyczące usługi RSS>>

C0000000 10010000 00000000 00000600 ................

F8000000 18000000 040000C0 F0000000 ................

90882612 D164D011 A9B000A0 248903EA ..&..d......$...

481D0000 65000000 01000000 01000000 H...e...........

00000000 00000000 00000000 00000000 ................

00000000 00000000 00000000 00000000 ................00000000 00000000 00000000 00000000 ................

00000000 01000080 6ec3c045 5dc3be01 ........n..E]...

32A85EDB 402BD311 8C6100C0 4F536AF2 2.^.@+...a..OSj.

B604A272 502F0800 8C6700C0 4F536AF2 ...rP/...g..OSj.007C1D00 00000000 00B80E00 00000000 .|..............

FA000000 00000000 0FB40E00 00000000 ................633591FC 5CC3BE01 13AE0000 00000000 c5..\...........

01000000 00000000 00000000 00000000 ................

00000000 00000000 0FB40E00 00000000 ................

00000000 01000000 E97D397C 00000000 .........}9|....

Dynamiczne wskaźniki lokalizacji danych (reparse points) — podsumowanie

Oto najważniejsze informacje dotyczące dynamicznych wskaźników lokalizacji danych (reparse points):

Folder nie może być wykorzystany jako katalog dołączania (mount point), jeśli zapisane są w nim jakiekolwiek pliki lub katalogi. Po ustanowieniu folderu katalogiem dołączania (mount point), dodawane do niego pliki lub katalogi są również dodawane do dołączonego katalogu.

Atrybut $Reparse w rekordzie MFT wyklucza dodawanie rozszerzonych atrybutów systemu plików HPFS. Nie stanowi to ograniczenia, ponieważ HPFS nie jest już obsługiwany.

Właściwości katalogu macierzystego, tzn. woluminu NTFS zawierającego katalog dołączania (mount point), nie podają pojemności i bieżącej statystyki plików woluminu dołączonego (lub woluminów dołączonych). Na przykład wolumin 8 MB, do którego dołączono jako katalog dołączania (mount point) wolumin 32 MB, zapytany przez system operacyjny, podaje 8 MB jako swój rozmiar.

Szukanie woluminu macierzystego lub uruchomienie programu usługowego DOS, takiego jak TREE, obejmuje zawartość każdego woluminu dołączonego.

Plik lub katalog mogą mieć tylko jeden wskaźnik lokalizacji danych (reparse point). Aplikacja wykorzystująca je musi posługiwać się prowizorycznymi rozwiązaniami problemu, który pojawi się, jeśli inna aplikacja dostanie się do danego rekordu jako pierwsza.

Wolumin może być dołączany do kilkunastu katalogów dołączania (mount points), ale jest to zalecane tylko w wyjątkowych wypadkach. Popatrzmy na problemy, jakie mają użytkownicy z mapowanymi dyskami logicznymi. Dodatkowy bałagan mógłby być spowodowany posiadaniem dwóch katalogów dołączania, wyglądających na niezależne, ale zawierających te same dane. Prawdopodobieństwo pojawienia się chaosu zwiększa możliwość występowania dwóch katalogów dołączania (mount points) jako dwóch różnych udziałów (share points). „Skopiowałem wszystkie moje pliki do --> K:\MyData[Author:E] , potem skasowałem R:\MyData, a teraz nie widzę żadnych plików w katalogu K:\MyData. Co się stało?”

Kopiowanie katalogu z dołączonym woluminem powoduje również kopiowanie dołączonego woluminu.

Usunięcie katalogu dołączania (mount point) z wykorzystaniem polecenia RD kasuje tylko rekord MFT zawierający wskaźnik lokalizacji danych (reparse point). Pliki w woluminie dołączonym pozostają nietknięte. Jeśli jednakże katalog dołączania był skasowany poleceniem DEL lub, wykorzystując Eksploratora, przeniesiony do Kosza albo usunięty, wszystkie pliki w woluminie dołączonym zostaną skasowane.

Archiwizując woluminy zawierające katalogi dołączania (mount points) otrzymujemy archiwum zawierające pliki i katalogi z woluminu dołączonego. Należy pamiętać o tym dołączając wolumin do wielu katalogów dołączania (mount points), ponieważ w rezultacie można archiwizować ten sam wolumin wiele razy. NTBACKUP ma opcję opuszczania odtwarzania z katalogów dołączonych i plików w tych katalogach.

Po dołączeniu woluminu do folderu dodatkowy obszar dostępny w woluminie nie jest zgłaszany systemowi operacyjnemu, a pliki nie pojawiają się w strukturze woluminu.

Odzyskiwanie systemu plików (File System Recovery) i odporność na uszkodzenia (Fault Tolerance)

System plików jest najbardziej krytycznym elementem systemu operacyjnego. Jeśli system plików ulegnie zniszczeniu, to dane mogą być nie tylko utracone całkowicie, ale też pomieszane w sposób nie od razu zauważalny. Przyczyny takiego zdarzenia mogą być różne. Dysk może ulec zniszczeniu lub mieć wiele sektorów uszkodzonych. Może nastąpić zanik zasilania na skutek awarii UPS lub braku UPS, a informacje dotyczące systemu plików znajdują się w pamięci podręcznej (cache). Źle zachowujący się sterownik może zablokować system lub uruchamiać się niepohamowanie poprzez pliki metadanych systemu plików. Przywrócenie spójności systemowi plików jest tak samo pilne dla administratora systemu, jak przywrócenie oznak życia dla lekarza pogotowia ratunkowego. W niniejszym paragrafie omówiono następujące zagadnienia: sprawdzanie „stanu zdrowia”, konieczne dla zapewnienia stabilnej pracy, odporność na uszkodzenia, szybkie odtwarzanie indeksów z wykorzystaniem dziennika zmian (Change Log) oraz działanie systemu ochrony plików systemowych (System File Protection). Na początek zostanie omówiona okresowa konserwacja i „stary znajomy”, Chkdsk.

Chkdsk i Autochk

Pierwszą linią obrony przed uszkodzeniami systemu plików jest okresowa konserwacja. Narzędzie systemowe Windows 2000 służące temu celowi nosi nazwę Chkdsk. Program ten analizuje system plików pod względem awarii i spójności oraz naprawia wszystkie znalezione uszkodzenia. Program, który sprawdza system plików, związany z Chkdsk, jest zawarty w samych sterownikach systemów plików: UFAT.DLL dla sytemu FAT i FAT32 oraz UNTFS.DLL dla systemu plików NTFS. Program ten może być uruchomiony na kilka innych sposobów niż poleceniem Chkdsk. Można użyć Eksploratora, klikając prawym klawiszem myszy na ikonę dysku, wybierając z menu opcję Właściwości (Properties), wybierając zakładkę Narzędzia (Tools), a następnie klikając Check Now. Można też rozpocząć sprawdzanie spójności systemu plików w trakcie uruchamiania systemu, wykorzystując program Autochk.

Porównanie programów Autochk i Chkdsk

Program Autochk można nazwać wersją startową (boot-time version) Chkdsk. Jest on zaprojektowany do pracy w trybie rzeczywistym podczas uruchamiania systemu, aby zapobiec blokowaniu sprawdzania spójności przez pliki zablokowane (locked files) i nie może zostać uruchomiony po załadowaniu systemu operacyjnego. Pozycja Rejestru kontrolująca pracę programu Autochk wygląda następująco:

Key: HKLM|System|CurrentControlSet|Control|SessionManager

Value: BootExecute

Data: Autocheck autochk * <<note: "Autocheck" is placeholder, "autochk" is the executable.>>

W normalnych warunkach Autochk jest uruchamiany tylko wtedy, kiedy ustawiony jest znacznik błędu („dirty” flag), co oznacza nieprawidłowe zamknięcie systemu. Autochk sprawdza dysk w trybie tylko do odczytu i zapisuje problemy do dziennika aplikacji (Application log). Szczegółowe informacje podaje Event Viewer.

Wykrywanie przyczyn częstego działania Autochk

Jeśli okaże się, że Autochk działa przy każdym uruchomieniu komputera, a nikt nie zmienił wartości domyślnych w Rejestrze, oznacza to poważny problem z podsystemem dysków. Najczęstszą przyczyną jest sprzętowa realizacja zapisu na dysk z wykorzystaniem pamięci podręcznej (hardware cache), która nie jest obsługiwana przez Windows 2000. Pamięć podręczna sprzętowa i programowa realizacja zapisu na dysk z wykorzystaniem pamięci podręcznej (software cache), zastosowana w Windows 2000, mogą utracić synchronizację, powodując uszkodzenie systemu plików. Jeśli nie ma absolutnej pewności, że wykorzystywana w danym komputerze macierz RAID lub kontroler SCSI mają pamięć podręczną obsługiwaną przez Windows 2000, to należy wyłączyć sprzętowe wykorzystanie pamięci podręcznej.

Wykorzystanie Chkntfs do konfigurowania Autochk

Autochk powinien być uruchamiany w trybie naprawiania napotykanych uszkodzeń (fixup mode) przy każdym uruchomieniu systemu, aby problemy z systemem plików zostały uchwycone i poprawione zanim zdążą doprowadzić do poważnych uszkodzeń. Można dokonać tego poprzez wpisanie parametru /p do pozycji Rejestru, dotyczącej Autochk, na przykład autochk /p *. Prostszym sposobem jest wykorzystanie programu Chkntfs. Poniżej podano ustawienia Chkntfs i składnię ustawień dotyczących Autochk. W każdym przypadku <wolumin> może również być literą dysku.

chkntfs <wolumin> /c. Powoduje uruchomienie Autochk w trybie automatycznego naprawiania napotkanych uszkodzeń dla podanego woluminu lub dysku. Ten parametr wpisuje /m do pozycji Rejestru dotyczącej Autochk.

chkntfs <wolumin> /d. Przywraca stan pierwotny ustawień Autochk, tzn. znacznik błędu (dirty flag) uruchamia go w trybie tylko do odczytu.

chkntfs <wolumin> /t:time. Sprawdzanie systemu plików może programowi Autochk zająć dużo czasu. Program ten pracuje w trybie rzeczywistym, więc ma do dyspozycji niewiele pamięci. W przypadku systemów wykorzystujących duże macierze RAID zawierające tysiące megabajtów plików, sprawdzenie może trwać kilkanaście godzin. Powyższa postać polecenia chkntfs ustawia odliczanie czasu, co pozwala na ominięcie sprawdzania mając uzasadnione przekonanie, że nie występuje żadne uszkodzenie systemu plików. Na przykład, zamykając system na serwerze, aby zainstalować nową kartę sieciową, można ustawić opcję /t:time pozwalającą ominąć drobiazgowe sprawdzanie. Opcja ta dodaje wartość AutoChkTimeOut do HKLM|System|CurrentControlSet|Control|Session Manager.

chkntfs <wolumin> /x. Wyłącza działanie Autochk dla podanego dysku. Korzystanie z tej opcji wymaga zachowania szczególnej ostrożności. Jeśli zapomni się o ustawieniu tego przełącznika, system nigdy nie wykona niezbędnego sprawdzenia podczas uruchamiania. Opcja ta dodaje wartość /k:<wolumin> do pozycji w Rejestrze odpowiadającej programowi Autochk.

Opis działania Chkdsk (Autochk)

Chkdsk (lub Autorun) wykonują szereg testów spójności systemu plików. Takie sprawdzenie systemu plików przebiega następująco.

--> Etap 1[Author:PGon]

Szuka w MFT aktywnych plików oraz rekordów katalogów i tworzy mapę bitową aktywnych rekordów MFT i aktywnych jednostek alokacji (wykorzystując numer LCN w rekordach).

Wykorzystuje mapę bitową do stwierdzenia ważności pliku metadanych $Bitmap. Jeśli rekord jest nieczytelny lub jego postać jest nieprawidłowa, zostaje to zakwalifikowane jako problem.

Etap 2

Przeszukuje rekordy katalogów, żeby upewnić się, że każda pozycja dotycząca pliku wskazuje rzeczywisty rekord pliku i uzgadnia z informacjami dotyczącymi katalogu zawartymi w rekordzie pliku.

Sprawdza odwołania (zależności) kołowe (circular reference), występujące bardzo rzadko, ale mogące spowodować utratę danych poprzez „osierocenie” wielkich połaci systemu plików, więc nie można traktować ich lekceważąco.

Sprawdza spójność pomiędzy rekordami plików w rekordach plików, a pozycjami dotyczącymi nazw plików w indeksie katalogu. Ten przebieg może zająć wiele minut, nawet godzin, zależnie od liczby pozycji MFT i stopnia złożoności katalogu. Rozmiar woluminu nie ma wpływu na prędkość. Sprawdzenie woluminu 32 GB z 1000 plików trwa mgnienie oka. Sprawdzenie 32 GB woluminu z --> 100,0000 [Author:UP] plików trwa bardzo długo.

Etap 3

Przeszukuje deskryptory ochrony (security descriptor), aby upewnić się, czy każdy rekord odwołuje się do deskryptora ochrony i czy każda pozycja zgadza się z zawartością tego deskryptora. Sposób przeszukiwania został znacząco zmieniony w Windows 2000 z powodu zmiany sposobu zapamiętywania deskryptorów ochrony (security descriptors). Ten etap sprawdzania w Windows NT zajmuje programowi Chkdsk dużo czasu, ale w przypadku Windows 2000 sprawdzenie odbywa się całkiem szybko.

Jeśli z danym woluminem związany jest dziennik zmian (Change Log) (USN Journal), to wtedy system przeszukuje go i weryfikuje indeksy. Więcej informacji w paragrafie „Śledzenie indeksów (Index Tracking) i dziennik zmian” (Change Journal) w dalszej części niniejszego rozdziału.

Etap 4

Wykonuje skanowanie dysku i próbuje odczytać każdy z sektorów, zawierających plik. Uszkodzone jednostki alokacji zostają umieszczone w wykazie $BadClus. Dane z uszkodzonych jednostek alokacji są kopiowane do nowych jednostek alokacji.

Etap 5

Wykonuje sprawdzenie wolnego obszaru woluminu. Uszkodzone jednostki alokacji zostają umieszczone w wykazie $BadClus.

Opcje programu Chkdsk

Program Chkdsk ma kilka opcji modyfikujących proces przeszukiwania. Dwie z nich, /i oraz /c zostały wprowadzone w NT4 SP4, żeby przyspieszyć sprawdzanie spójności poprzez ominięcie etapów 4 i 5. Te same opcje dotyczą programu Autochk.

/f - Uruchamia Chkdsk w trybie automatycznego naprawiania wykrytych uszkodzeń (fixup mode). (W przypadku Autochk opcja ta ma postać /p.)

/v - Wyświetla komunikaty o wykonywanych operacjach.

/r - Wykonuje pełne sprawdzenie dysku w poszukiwaniu uszkodzonych jednostek alokacji. Każda taka jednostka jest dopisywana do pliku $BadClus.

/l - Wyświetla rozmiar $Logfile. Podanie parametru :size, np /l:4096, zmienia rozmiar $Logfile.

/x - Wymusza odłączenie woluminu. Użytkownicy, którzy mają otwarte pliki, tracą swoje dane. Wykorzystanie tej opcji uruchamia również Chkdsk w trybie automatycznego naprawiania wykrytych uszkodzeń (fixup mode).

/i - Pomija sprawdzenie wewnętrznej spójności pomiędzy atrybutami nazw plików w rekordach plików i powiązanym wykazem nazw plików w indeksie katalogu.

/c - Pomija cykliczne sprawdzanie katalogu.

Zalecenia dotyczące wykorzystania programu Chkdsk

W celu wykrycia nieprawidłowości w systemu plików, program Chkdsk powinien być uruchamiany okresowo. Nie można wykorzystywać programu Chkdsk dla woluminu z plikami aktywnymi, takimi jak wolumin systemowy lub wolumin zawierający bazę danych, ponieważ dostęp do plików jest zablokowany. Można wykorzystać program Chkntfs i zaplanować uruchomienie Autochk w czasie uruchamiania systemu.

W przypadku użytkowników, którzy ciągle powodują uszkodzenia plików w systemie Windows 2000 Professional, należy oduczyć ich wyłączania komputera bez zamykania systemu poprzez ustawienie programu Autochk w tryb automatycznego naprawiania wykrytych uszkodzeń (fixup mode) przy każdym uruchomieniu systemu. Trzeba wyjaśnić, że ten dodatkowy czas, potrzebny na rozruch systemu rano jest konieczny, bo system nie został poprawnie zamknięty wieczorem.

Dziennik zdarzeń systemu plików

W większości przypadków Chkdsk lub Autochk, uruchomione w trybie automatycznego naprawiania wykrytych uszkodzeń (fixup mode), naprawiają wszystkie nieprawidłowości systemu plików. Ale co się stanie, jeśli system plików znajduje się w nieznanym stanie spowodowanym przez awarię systemu lub zanik zasilania? Wiele danych aktywnych w systemie Windows 2000, zanim zostaną przesłane na dysk, zapisane są w pamięci podręcznej, ponieważ przyjęto założenie, że aplikacje korzystają stale z tych samych danych. Ta właściwość systemu plików zwana powolnym zapisem (lazy write) z pamięci podręcznej, znacznie poprawia wydajność systemu jednakże za cenę pogorszenia niezawodności systemu plików.

Jeśli system plików znajdzie się w stanie nieznanym w następstwie awarii lub blokady, Autochk potrafi odbudować go, ale przebiega to bardzo powoli. Serwery i stacje robocze są znane z tego, że od czasu do czasu ulegają awariom, więc sensowne jest przygotowanie się na taką ewentualność stosując sposób szybszego odzyskania spójnego systemu plików. W systemie plików NTFS istnieje usługa o nazwie LFS, pracująca w trybie jądra (kernel mode service).

LFS jest usługą ogólnego przeznaczenia, zapisującą komunikaty do dzienników zdarzeń, ale obecnie NTFS jest jedynie klientem tej usługi.

Budowa LFS

Usługa ta rejestruje wszystkie zapisy na dysk wpływające na rdzeń systemu plików. Informacje te zapisane są w jednym z plików metadanych MFT o nazwie $Logfile. Plik $Logfile zawiera zestaw 4-kilobajtowych ciągów jednostek alokacji umieszczonych w środku dysku. Zwykle początkowy rozmiar pliku wynosi 2 MB. Tworzona jest również 2-megabajtowa kopia pliku $Logfile.

Dane użytkownika nie są chronione przez usługę LFS. Naciśnięcie dużego czerwonego wyłącznika na stacji roboczej lub serwerze powoduje utratę wszystkich danych użytkownika znajdujących się w pamięci podręcznej. W takiej sytuacji przywrócenie spójności systemowi plików może zająć programowi Autochk dużo czasu.

Rekord $Logfile ma postać standardowego rekordu pliku MFT. Zawiera wskaźnik do nierezydentnego atrybutu $Data reprezentującego dziennik zdarzeń. Sam dziennik zdarzeń (log) zaczyna się pośrodku woluminu, zaraz za kopią MFT. Jeśli dysk był poddany konwersji z systemu plików FAT lub FAT32 i w środku dysku zapisane już są pliki, dziennik zdarzeń (log) umieszczany jest w ciągłym obszarze wolnym odpowiedniego rozmiaru w dowolnym miejscu dysku. Jeśli nie można znaleźć wystarczająco dużego obszaru wolnego, to wtedy dochodzi do fragmentacji pliku dziennika zdarzeń. Może to obniżyć wydajność systemu.

System pliku dziennika zdarzeń — przegląd funkcji

Plik $Logfile składa się z dwóch części: obszar ponownego startu (restart area) oraz obszar nieskończonego zapisywania zdarzeń (infinite logging area). Obszar ponownego startu (mieszczący się w buforach rozpoczynających się od ciągu znaków RSTR) zawiera informacje o lokalizacji danych w obszarze zapisywania zdarzeń. Głównym składnikiem obszaru ponownego startu jest wskaźnik kontrolny (checkpoint), podający systemowi zapisywania zdarzeń, które zdarzenia zostały wpisane do MFT, a które nie. Obszar nieskończonego zapisywania zdarzeń (zawarty w buforach rozpoczynających się od ciągu znaków RCRD) działa jak ośmiościeżkowa taśma. Kiedy dziennik zdarzeń zapełnia się, usługa zapisywania zdarzeń przechodzi na początek obszaru, nadpisując najstarsze pozycje.

Kiedy nastąpi aktualizacja rdzenia systemu plików (core file system), obsługa zapisu na dysk jest przekazywana do usługi LFS, która dokonuje wpisu do pliku $Logfile. Te niezbędne aktualizacje obejmują zmiany nagłówków atrybutów, atrybutów ochrony, lokalizacji katalogów i modyfikacje plików metadanych MFT.

Pozycje dziennika zdarzeń są okresowo wpisywane do MFT, a wskaźnik kontrolny (checkpoint) przesuwa się. W razie awarii systemu w trakcie tej operacji, usługa LFS może bardzo szybko odtworzyć spójność systemu plików, znajdując po prostu wskaźnik kontrolny (checkpoint) i przechodząc przez ostatnie pozycje pliku $Logfile. Następnie usługa LFS usuwa każdą niedokończoną operację i ponawia próbę zapisu. Końcowy stan MFT odzwierciedla status systemu plików w momencie awarii, z wyłączeniem informacji czekających w pamięci podręcznej na zapis do dziennika zdarzeń.

Odtwarzanie systemu plików z wykorzystaniem dziennika zdarzeń systemowych w przypadku woluminów o dużych rozmiarach może trwać dłuższą chwilę, ale nie tak długo, jak pełna odbudowa systemu przy użyciu programu Autochk. Jeśli odtwarzanie wykorzystujące dziennik zdarzeń systemowych nie powiedzie się, system plików wykonuje pełną odbudowę. Jeśli to się nie powiedzie, jedynym wyjściem jest odzyskanie systemu z taśmy. Nie są dostępne żadne parametry sterujące, ani wpisy do Rejestru dotyczące usługi LFS.

Jedynym indeksem odtwarzanym przez LFS jest indeks nazw plików w rekordach katalogów. Kilka składników systemu Windows 2000 wymaga specjalnego indeksowania MFT. Odzyskiwanie tych indeksów poprzez pełne przeszukiwanie tablicy jest nudnym procesem. System Windows 2000 ma nową właściwość przyspieszającą ten proces. Jest dziennik zmian (Change Journal), omówiony w następnym paragrafie.

Śledzenie indeksów (Index Tracking) i dziennik zmian (Change Journal)

Od wprowadzenia systemu plików NTFS, firma Microsoft ogłaszała zdolność systemu do obsługi aplikacji, dostarczanych przez firmy zewnętrzne (third-party), indeksujących atrybuty inne niż $File_Name. Ale dostawcy z oporem piszą takie programy, z powodu niewystarczającej dokumentacji na temat LFS, braku wydajnych narzędzi do zarządzania LFS i konieczności poświęcenia ogromnego nakładu pracy na ponowne indeksowanie po odzyskaniu pliku dziennika zdarzeń.

W systemie Windows 2000 firma Microsoft spróbowała rozwiązać ten problem poprzez dodanie nowej właściwości o nazwie dziennik zmian (Change Journal). Dziennik zmian zawiera ślad zmian wprowadzonych do MFT, które wpływają na pozycje indeksowane. Na przykład, wskaźnik lokalizacji danych (reparse point) wykorzystuje atrybut $Reparse_Point i indeks zawarty w rekordzie metadanych o nazwie $Reparse. Dziennik zmian (Change Journal) umożliwia szybkie odzyskiwanie tego wskaźnika.

Firma Microsoft ogłosiła dziennik zdarzeń technologią poprawiającą wydajność aplikacji stosujących indeksy systemu plików i zależnych od aktualnych danych o zmianach w systemie plików. Są to programy do archiwizacji, programy antywirusowe i narzędzia dyskowe. Jeśli programiści polubią możliwości, które daje dziennik zdarzeń (Change Journal), to wtedy pojawi się więcej aplikacji wykorzystujących go. Aplikacjami wykorzystującymi dziennik zdarzeń (Change Journal) systemu Windows 2000 są:

Usługa indeksowania zawartości (Content Indexing Service). Usługa indeksowania śledzi dane potrzebne do szybkiego odzyskiwania i jest uzupełniona przez program CISVC i CIDAEMON.DLL.

Usługa replikacji plików (File Replication Service — FRS). Usługa FRS automatycznie pobiera dane z jednego serwera i kopiuje je do innego. Proces ten jest bardziej wydajny, niż proste użycie programu XCOPY jako polecenia wsadowego, ponieważ kopiowane są tylko zmiany, a nie całe katalogi. Usługa FRS obsługuje dwie kluczowe własności Windows 2000: rozdzielanie założeń systemowych dotyczących grup (group policies) pomiędzy kontrolerami domeny i rozdzielanie plików współdzielonych (shared files) pomiędzy partnerami replikacji w systemie plików rozproszonych (Distributed File System — DFS).
Usługi zdalnego przechowywania danych (Remote Storage Services — RSS). Pliki są przenoszone z dysku na taśmę, ale usługa ta umożliwia dostęp do nich w trybie „prawie online”. Dziennik zmian (Change Log) skraca czas odzyskiwania i znacznie obniża ryzyko utraty danych spowodowane przez uszkodzone lub niespójne bazy danych.

Dziennik zmian — przegląd

Dziennik zmian (Change Journal) jest rekordem metadanych o nazwie $UsnJrnl zapisanym w folderze metadanych $Extend. W tablicy 13.3 przedstawiono zdarzenia, które powodują wpis do dziennika zmian (Change Journal) dla indeksowanych rekordów:

Tablica 13.3. Zdarzenia, które powodują wpis do dziennika zmian (Change Journal)

Basic_Info_Change Hard_Link_Change

Close Indexable_Change

Compression_Change Named_Data_Extend

Data_Extend Named_Data_Overwrite

Data_Overwrite Named_Data_Truncation

Data_Truncation Object_Id_Change

Ea_Change Rename_New_Name

Encryption_Change Rename_Old_Name

File_Create Reparse_Point_Change

File_Delete Security_Change

Stream_Change

System śledzi zmiany w dzienniku zmian (Change Journal) wykorzystując numer kolejny aktualizacji (Update Sequence Number — USN). Jeśli dokonywany jest wpis do dziennika zmian lub aktualizacja któregokolwiek z wpisów, to otrzymuje kolejny dostępny numer USN. Sposób ten podobny jest do tego, który wykorzystuje Active Directory do śledzenia zmian. Numery USN są 64-bitowe, więc wystarczy ich na miliardy lat.

Brak wskazówek dotyczących wykrywania usterek, związanych z działaniem dziennika zmian (Change Journal). Dziennik zdarzeń jest przejrzysty, tak jak system plików dzienników zdarzeń (Log File System). Nie ma żadnych ustawień interfejsu użytkownika ani pozycji Rejestru dostępnych dla administratora. Jeśli dziennik zmian zostanie uszkodzony lub przypadkowo skasowany, aplikacja która korzysta z niego jest zmuszona wykonać pełne przeszukiwanie MFT w celu ponownego indeksowania. Może to chwilę potrwać. Gdyby ponowny start systemu wydawał się nadmiernie długi, należy sprawdzić zawartość dziennika zdarzeń (Event Log).

Dziennik zmian (Change Journal) — podsumowanie

Oto najważniejsze informacje dotyczące dziennika zmian (Change Journal):

Dziennik zmian (Change Journal) jest nowością w Windows 2000.

Dziennik zdarzeń przyspiesza odzyskiwanie składników systemu Windows 2000, które indeksują inne atrybuty MFT niż nazwy plików.

Aplikacje zachowujące indeksy MFT muszą rozważnie dokonywać wpisów do --> dziennika[Author:UP] .

Ochrona plików systemowych (System file protection)

Bardziej podstępne błędy pliku niż zawieszanie się systemu, czy błędna postać indeksów, mają mniejszy związek z systemem plików, niż z plikami zapisanymi w tym systemie. Wszystkie 32-bitowe wersje Windows polegają bezwzględnie na spójnym zestawie procedur systemowych, bibliotek DLL i plików systemowych zapisanych w specjalnych folderach partycji systemowej/startowej. Każdy programista może modyfikować te składniki systemu operacyjnego nie pytając o pozwolenie. Jest serwer, który pracuje bez awarii długie miesiące. Po zainstalowaniu pozornie nieszkodliwej aplikacji niespodziewanie wyświetla niebieski ekran, przysparzając cierpień administratorowi systemu.

System Windows 2000 zawiera nową usługę zaprojektowaną z myślą o powstrzymaniu tego typu niepohamowanych igraszek z najważniejszymi plikami systemowymi. Usługa nosi nazwę ochrona plików systemowych (System File Protection) i prowadzi dziennik zdarzeń, związanych z tymi plikami oraz pozwala na ich modyfikacje jedynie w czterech przypadkach:

Instalowanie Service Pack przy użyciu UPDATE.EXE

Instalowanie programu Hotfix przy użyciu HOTFIX.EXE

Aktualizacja systemu operacyjnego przy użyciu WINNT32.EXE

Usługa Windows Update.

Każda próba zmiany pliku systemowego w jakikolwiek inny sposób zostaje zablokowana przez usługę SFP, która natychmiast wpisuje firmową wersję danego pliku na miejsce pliku z podejrzanymi zmianami.

Usługa SFP przechowuje kopie kontrolowanych przez siebie plików w skompresowanym folderze \WINNT\System32\DllCache. Ten folder zawiera kopię każdego z plików zainstalowanych przez procedurę Setup z instalacyjnej płyty CD Windows 2000. Po aktualizacji dowolnego z plików systemowych za pomocą którejkolwiek z akceptowalnych metod, do powyższego folderu zostaje wpisana wersja zmodyfikowana. Usługa SFP rozróżnia strzeżone pliki i ich wersje, porównując sygnaturę pliku z sygnaturą zapisaną w pliku NT5.CAT, znajdującym się także w folderze DllCache. Ochraniane pliki INF przechowywane są w pliku NT5INF.CAT.

Opis działania usługi SFP

Działanie usługi SFP można sprawdzić w następujący sposób:

Procedura 13.5 Sprawdzenie działania usługi SFP

Otwórz Eksploratora i przejdź do katalogu \WINNT\System32. Jeśli Eksplorator pracuje w trybie przeglądarki WWW, sprawdzeniu podlega prawo korzystania z katalogów \WINNT oraz \WINNT\System32. To jest wskazówka, że obydwa katalogi są na liście katalogów chronionych przez usługę SFP.
Przejdź do jednego z plików krytycznych Windows 2000, SOL.EXE.
Kliknij prawym klawiszem myszy na ikonie SOL.EXE i z menu wybierz opcję Usuń (Delete). Potwierdź operację kasowania pliku.
Czekaj i obserwuj, co się stanie. Po kilku sekundach ikona SOL.EXE pojawi się ponownie. To jest właśnie usługa SFP przy pracy.

Składniki usługi SFP

SFP nie można uruchomić jako oddzielnej, niezależnej usługi, ponieważ jest ona nieodłącznym elementem systemu operacyjnego. Parametry sterujące usługi wpisane są do Rejestru systemowego w kluczu HKLM|Software|Microsoft|Windows NT|Current Version|Winlogon. Wartości tych parametrów są następujące:

SFCQuota. Rozmiar obszaru dysku przydzielony dla katalogu DllCache. Wartością domyślną jest --> ffffffff[Author:UP] , co daje rozmiar równy 4 GB. Ten sam efekt można osiągnąć wprowadzając wartość -1.

SFCDisable. Ustawienie wartości na 1 powoduje zablokowanie usługi SFP podczas następnego restartu systemu. Przy kolejnych startach działanie tej usługi jest automatycznie włączone. Ten wyłącznik może być użyty w razie zamiany plików na wersje autoryzowane, opracowane przez dostawców oprogramowania lub wykorzystania sprawdzonych wersji plików do wyszukiwania błędów.

SFCBugCheck. W normalnych warunkach, przy każdej próbie zamiany lub usunięcia pliku chronionego, system wysyła komunikat ostrzegający. Po ustawieniu tego parametru na 1 system blokuje się, wyświetlając niebieski ekran. Taką wartość można ustawić dla użytkownika, który próbował zmieniać pliki systemowe.

SFCScan. Kontroluje przeszukiwanie folderu DllCache w poszukiwaniu brakujących plików podczas uruchamiania systemu. Wartość 1 przeszukuje pliki przy każdym uruchomieniu, wartość 2 przeszukuje pliki jednorazowo.

Stosowanie analizatora plików systemowych (System File Checker — SFC)

W celu zmiany ustawień usługi SFP nie jest konieczne dokonywanie zmian w Rejestrze. W skład systemu Windows 2000 wchodzi program narzędziowy do sprawdzania plików systemowych o nazwie System File Checker (SFC). SFC odbudowuje również folder DllCache, jeśli pliki zostałyby przypadkowo skasowane. Poniżej opisano parametry programu SFC.

sfc /scanonce

Ta opcja powoduje sprawdzenie zgodności zawartości foldera DllCache z sygnaturami zapisanymi w pliku CAT, a następnie sprawdza pliki w chronionych katalogach. Procedura ta jest wykonywana po zalogowaniu się użytkownika.

Równocześnie z programem SFC można uruchomić inne zadania i aplikacje, ale spowalnia to proces przeszukiwania folderu. Jeśli system napotka plik, którego brakuje w folderze DllCache, wysyła komunikat z prośbą o włożenie do napędu dysku instalacyjnego Windows 2000, by go odtworzyć.

Pomimo zainstalowania Windows 2000 z sieci lub z katalogu I386 na lokalnym dysku twardym, konieczne jest posiadanie wersji instalacyjnej Windows 2000 na płycie CD-ROM. Jeśli komputer nie ma napędu CD-ROM, jedynym wyjściem z sytuacji jest porównanie zawartości foldera DllCache danego dysku twardego z tym samym folderem na dysku w innym komputerze i ręczne skopiowanie brakujących plików.

sfc /scanboot

Ta opcja powoduje przeglądanie plików chronionych przy każdym uruchomieniu systemu. W przypadku serwerów administrowanych profesjonalnie ma to miejsce bardzo rzadko. Z drugiej strony, komputery użytkowników mogą wymagać większej dbałości. Polecenie w takiej postaci stosuje się w przypadku problemów z użytkownikami, którzy kasują pliki z folderu DllCache, żeby sami przeprowadzili nudny proces poprawiania swoich własnych błędów. W przypadku, jeśli ten sam użytkownik ciągle zmienia pliki ochraniane, można także wykorzystać parametr /SFCBugCheck, zapisany w Rejestrze, do zablokowania komputera i wyświetlenia niebieskiego ekranu.

sfc /quiet

Powoduje zamianę brakujących plików bez pytania o zezwolenie.

sfc /cancel

Tę opcję wykorzystuje się w przypadku, jeśli system ma wykonać przeszukiwanie przy następnym uruchomieniu, ale administrator zmienił zdanie.

Usługa SFP — podsumowanie

Oto najważniejsze informacje dotyczące usługi SFP:

Usługa SPF ochrania pliki systemowe załadowane podczas instalacji systemu.

Usługa SFP zezwala na dokonywanie zmian w plikach systemowych tylko nielicznym procedurom systemowym.

Pliki systemowe, które zostały usunięte lub zawierają błędy, są zastępowane poprawnymi z dyskowej pamięci podręcznej (on-disk cache).

Program użytkowy SFC, uruchamiany z wiersza poleceń, służy do przeglądania plików systemowych i ich naprawy.

Defragmentacja plików

Brak zintegrowanego programu do defragmentacji plików jest jedną z najbardziej jaskrawych wad Windows NT. Po pojawieniu się systemu Windows NT, firma Microsoft utrzymywała, że nie ma obniżenia wydajności systemu plików NTFS, jeśli dojdzie do fragmentacji dysku. Zaleceniem firmy było powtórne formatowanie i odtworzenie z kopii zapasowej. Prawie na zakończenie prac nad Windows NT 3.51, firma o nazwie Executive Software opracowała program narzędziowy dla NT o nazwie Diskeeper do przeprowadzania defragmentacji woluminów NTFS i FAT. Pierwsza wersja wymagała specjalnych zabiegów umożliwiających dostęp do systemu plików. Firma Microsoft, na żądania Executive Software, zgodziła się włączyć do Windows NT 4 specjalne wywołania systemowe (API calls) obsługujące defragmentację, więc żadne specjalne zabiegi nie są już konieczne. Te same wywołania (API calls) są wykorzystywane w Windows 2000, ale procedury, które się za nimi kryją mają inną postać.

Wywołania API opracowane przez Microsoft dla celów defragmentacji korzystają z rodzimych procedur systemowych, które są tak bezpieczne jak system. System może odtworzyć strukturę pliku nawet w przypadku zaniku zasilania podczas defragmentacji.

W Windows 2000 zawarta jest ograniczona wersja programu Diskeeper, uruchamiana za pomocą konsoli MMC o nazwie Disk Defragmenter (Defragmentacja dysku), lub Dfrg.msc. Program jest funkcjonalnym odpowiednikiem produktu firmy Executive Software „Diskeeper Lite for NT”, z tym, że wersja dla Windows 2000 obsługuje FAT, FAT32, NTFS4 i NTFS5. Sam program do defragmentacji składa się z dwóch procedur: Dfrgfat.exe i Dfrgntfs.exe. Dfrgfat obsługuje systemy woluminów FAT i FAT32.

Defragmentacja a wydajność systemu

Doprowadzenie do takiego stopnia fragmentacji woluminu NTFS, w którym daje się zauważyć obniżenie wydajności systemu, nie jest takie proste. Fragmentacja woluminu zwykle nie stanowi żadnego problemu, dopóki stopień wykorzystania woluminu nie przekroczy 90%, nie będzie wykorzystywania kompresji lub, o ile nie dojdzie do fragmentacji pliku, stronicowania (paging file) lub MFT.

Niektórzy ludzie zaklinają się, że defragmentacja nie ma żadnego wpływu na wydajność. Inni głoszą, że jest wręcz przeciwnie. Firma Executive Software wykorzystała usługi NSTL, www.nstl.com, pozwalające na wykonanie testów wydajności, porównujących systemy, w których doszło do fragmentacji z takimi, w których ten problem nie występuje. Wyniki pokazują, że duży stopień fragmentacji woluminu, zwłaszcza jeśli doszło do fragmentacji pliku stronicowania (paging file), może poważnie obniżyć wydajność. Nie wykonuje się testów w przypadku woluminów o niewielkim stopniu fragmentacji zdarzającej się w przypadku woluminów z dużym obszarem wolnym na dysku i plików o różnych rozmiarach.

Ograniczenia procedury defragmentacji

Zanim procedura defragmentacji Windows 2000 zostanie opisana bardziej szczegółowo, poniżej przedstawiono wykaz jej ograniczeń:

Defragmentacja nie wpływa na plik stronicowania (paging file). Duży plik stronicowania (paging file) na obciążonym serwerze może składać się z setek fragmentów, a plik stronicowania (paging file), który uległ fragmentacji obniża wydajność w stopniu większym niż inne czynniki. Hamuje również defragmentację innych plików, blokując dostęp programu defragmentacji do ciągłych obszarów jednostek alokacji.

Defragmentacja nie wpływa na MFT. Fragmentację MFT można osiągnąć poprzez konwersję dysku, na którym zapisana jest bardzo duża liczba plików lub zezwolenie systemowi NTFS na pozostawienie mniej, niż 25% wolnej przestrzeni. Jedynym wyjściem w przypadku fragmentacji MFT jest ponowne sformatowanie woluminu i odzyskanie plików z kopii zapasowej. Więcej informacji w bloku uwag pod tytułem --> „Bufor MFT”[Author:PGon] .

Defragmentacja nie wpływa na zawartość Rejestru. Jeśli użytkownicy na swoich stacjach roboczych stale instalują i usuwają aplikacje, może dojść do znacznej fragmentacji Rejestru. Skuteczność programów narzędziowych, takich jak RegClean, jest umiarkowana.

Niewielka skuteczność defragmentacji plików skompresowanych. Przyczyna leży po stronie interfejsu programisty API, a nie procedury defragmentacji. Procedura MoveFile interfejsu API, przenosząca pliki w inne położenie, jednorazowo obsługuje parzystą wielokrotność 16 jednostek alokacji, tak samo, jak programy kompresujące. Oznacza to, że wolumin skompresowany jest podzielony na kawałki, z którymi procedura defragmentacji nie poradzi sobie.

Procedura defragmentacji nie „pakuje” plików. NTFS nie ma prawie żadnych korzyści z przeniesienia procedur systemowych, bibliotek DLL i innych plików tylko do odczytu na początek dysku.

Defragmentacja nie może być procedurą wsadową. Jest to cecha procedury defragmentacji w wersji dostarczanej wraz z Windows 2000. Nie można też ustawić defragmentacji jako zadania w tle. Procedura defragmentacji musi być uruchamiana z konsoli Disk Defragmenter (Defragmentacja dysku). Jedynym widocznym powodem takiego stanu rzeczy jest chęć odróżnienia systemowej procedury defragmentacji od wersji handlowej programu Diskeeper.

Wszystkie te ograniczenia, z wyjątkiem obsługi plików skompresowanych, można ominąć, stosując programy użytkowe do defragmentacji, dostępne na rynku. Firma Executive Software dostarcza wersję handlową programu Diskeeper, zawierającą dodatkowe procedury. Inne programy do defragmentacji to PerfectDisk firmy Raxco Software, www.raxco.com, oraz Norton SpeedDisk firmy Symantec, www.symantec.com. Dla Windows NT najlepiej porządkuje dysk program PerfectDisk, ale jest bardzo, bardzo wolny. Norton SpeedDisk jest najszybszy, ale wykonuje więcej przebiegów. Diskeeper jest najlepszą kombinacją szybkości i funkcjonalności.

Wskazówka dotycząca RejestruParametry sterujące defragmentacją dysku (Disk Defragmenter) znajdują się w kluczu HKLM|Software|Microsoft|Dfrg.

Bufor MFT (MFT Buffer)

Tablica MFT posiada bufor pozwalający jej na zwiększanie rozmiaru, nie ulegając fragmentacji. Wartością domyślną rozmiaru bufora jest 12,5% całkowitego obszaru woluminu. Na 18-gigabajtowym dysku sformatowanym jako jeden wolumin, rozmiar bufora MFT wynosi 2,25 GB. To wystarcza, aby w tablicy MFT mogło znaleźć się ponad 2 miliony plików i katalogów i tablica nie uległa fragmentacji.

Jeśli dysk zaczyna być pełny, system plików wkracza do bufora MFT. Od tej chwili może pojawić się plik nadmiarowy i dojdzie do fragmentacji MFT. Należy zawsze pozostawić wolne powyżej 15% całkowitego obszaru woluminu NTFS5.

Można zwiększyć rozmiar bufora. Obszar ten jest pozostawiony jak rezerwat leśny. Po zapełnieniu się pozostałej części dysku, system zapisuje bufor od końca, tak jak firma budująca molo. W celu zmiany rozmiaru bufora należy dokonać następujących wpisów do Rejestru:

Key: HKLM|System|CurrentControlSet|Control|FileSystem

Value: NtfsMftZoneReservation

Data: 1-4 (REG_WORD)

Wpisanie 1 oznacza 12,5% rozmiaru woluminu. Wprowadzenie 2 zwiększa rozmiar bufora do 25%. Wpisanie 3 daje 50%, a wpisanie 4 oznacza 75%. System ciężko pracuje, żeby bufor MFT pozostał nietknięty, więc jeśli bufor jest duży, to wtedy administrator jest częściej zmuszany do przeprowadzenia defragmentacji. Obecnie administrator rzadko ma potrzebę zmiany rozmiaru bufora, ponieważ rozmiar standardowy rekordu MFT wynosi tylko 1 kB.

Czyszczenie woluminu przed defragmentacją

Czy kiedykolwiek korzystałeś z usług gosposi? Co zrobiłeś przed pierwszą wizytą gosposi? Posprzątałeś dom, nieprawdaż? Przecież nie chcesz, by zupełnie obca osoba pomyślała, że jesteś brudasem. Tę samą zasadę stosuje się przy przygotowania woluminu do defragmentacji. Posiadanie dużej liczby plików bezużytecznych, które tylko zabierają niepotrzebnie czas przy defragmentacji, nie ma sensu. Przed uruchomieniem defragmentacji należy wykonać dwie czynności:

Uruchomienie programu chkdsk /f dla każdego woluminu, który ma być poddany defragmentacji. Może to oznaczać konieczność ponownego uruchomienia systemu, co spowoduje start programu Autochk dla partycji systemowej (rozruchowej). Do tej pory nie są znane przypadki awarii systemu podczas procesu defragmentacji, który został wykonany po zakończeniu działania programu Chkdsk.

Należy pozbyć się plików balastowych. Częścią systemu Windows 2000 jest program o nazwie Disk Cleanup (Czyszczenie dysku), w postaci pliku wykonywalnego Clnmgr.exe. Procedura czyszczenia dysku przeszukuje go rozpoznając stare pliki CAT, pliki tymczasowe związane z Internetem, tymczasowe i usunięte pliki dostępne offline oraz znajdujące się w Koszu, których usunięcie nie spowoduje żadnych problemów.

Dla stacji roboczych i serwerów specjalizowanych program Disk Cleanup jest szybkim i wydajnym sposobem usuwania niepotrzebnych plików. Program uruchamia się następująco:

Procedura 13.6 Wykorzystanie programu Disk Cleanup

Uruchom Disk Cleanup wybierając START|PROGRAMS|ACCESSORIES|SYSTEM TOOLS|DISK CLEANUP. Pojawi się okno Disk Cleanup (Czyszczenie dysku).
Podaj, który dysk ma być czyszczony. Procedura czyszczenia szuka plików — kandydatów do usunięcia. Jeśli na dysku są katalogi dołączania (mount point), wyszukiwanie obejmuje również woluminy dołączone. Po zakończeniu wyszukiwania Disk Cleanup podaje użytkownikowi wyniki w postaci menu. Zobacz rysunek 13.10. Wybór tymczasowych plików internetowych (Temporary Internet Files) do usunięcia, nie powoduje usunięcia cookies. Kasowane są strony WWW znajdujące się w pamięci podręcznej (cache), co może powodować opóźnienia w dostępie do różnych miejsc w sieci przy kolejnym uruchomieniu przeglądarki Internet Explorer.

Wybór Temporary Off-Line Files jest możliwy do przyjęcia nawet, jeśli użytkownik jest wylogowany lub zapomniał o synchronizacji. Pogram Disk Cleanup usuwa tylko te pliki offline, które są zaznaczone jako zsynchronizowane z plikiem źródłowym.

0x01 graphic

Rysunek 13.10. Okno Disk Cleanup (Czyszczenie dysku) przedstawiające opcje menu.

Wybierz, klikając, odpowiednią opcję, której chcesz użyć, a następnie naciśnij klawisz OK w celu dokonania zmian i skasowania plików. Po zakończeniu pracy programu Disk Cleanup (Czyszczenie dysku) okno zamyka się bez żadnego komunikatu końcowego.

Defragmentacja woluminu NTFS

Teraz użytkownik jest gotowy do uruchomienia defragmentacji woluminu. Konsolę Disk Defragmenter (Defragmentacja dysku) można wywołać na kilka sposobów:

Bezpośrednio z menu START: START|PROGRAMS|ACCESORIES|SYSTEM TOOLS|DISK DEFRAGMENTER.

Z konsoli Computer Management (Zarządzanie komputerem) poprzez rozszerzenie drzewa katalogu do STORAGE|DISK DEFRAGMENTER.

Z Eksploratora lub okna Mój komputer przez kliknięcie prawym klawiszem myszy na ikonie napędu, otwarcie okna Properties (Właściwości) i wybór opcji TOOLS|DEFRAGMENT NOW.

Z okna Uruchom przez wydanie polecenia dfrg.msc.

Po otwarciu konsoli Disk Defragmenter są dwie możliwości: uruchomienie analizy stanu fragmentacji woluminu lub przeskok do uruchomienia procedury defragmentacji. Zacznij od analizy.

Procedura 13.7 Wykonanie analizy defragmentacji

Zaznacz wolumin i kliknij Analyze (analiza). System szuka fragmentów i wyświetla raport w postaci graficznej i tekstowej. Rys 13.11 przedstawia przykład. Więcej informacji zawarto w dalszym ciągu niniejszego paragrafu.

0x01 graphic

Rysunek 13.11. Okno Defragmentacja dysku (Disk Defragmenter) prezentujące wyniki analizy dysku.

Najważniejsze informacje o defragmentacji

Woluminy bez nazw są dołączane do innych woluminów z wykorzystaniem katalogów dołączania. Defragmentacja woluminu zawierającego katalogi dołączania nie obejmuje defragmentacji woluminu dołączonego.

Każdy wolumin musi być wywoływany osobno. Przy użyciu programu Disk Defragmenter (Defragmentacja dysku) nie można przeprowadzić defragmentacji większej liczby woluminów jednocześnie. Można tego dokonać stosując jeden z wielu programów spoza systemu Windows 2000. Określenie pliki systemowe nie oznacza plików systemowych Windows 2000, lecz pliki systemowe NTFS, na które składają się: tablica MFT wraz z wszystkimi atrybutami nierezydentnymi, plikiem stronicowania (paging file) i Rejestrem.Nie bądź zdziwiony, widząc dużą liczbę plików rozsianych po całym dysku, podczas gdy analizator podaje, że wolumin nie musi być poddany defragmentacji. Do fragmentacji woluminu NTFS może dojść tylko wtedy, kiedy wiele nierezydentnych atrybutów danych jest rozdzielonych pomiędzy dużą liczbę ciągów jednostek alokacji. Raport końcowy w postaci tekstowej zawiera więcej informacji.

Kliknij View Report. Wydruk zawiera statystykę wykorzystania woluminu, fragmentacji woluminu, fragmentacji pliku, fragmentacji pliku stronicowania, fragmentacji katalogów i fragmentacji MFT. Z tego wykazu program defragmentacji usuwa tylko fragmentację katalogów i plików. Oczekuj, że znajdziesz prawie wszystkie informacje Rejestru w górnej części wykazu fragmentacji.Wybierz pozycję Defragmentacja (Defragment). Można to zrobić w oknie Report (Raport) lub w oknie głównym. System wykonuje jeszcze jedną analizę, a następnie rozpoczyna defragmentację. Jeśli wolumin jest duży i zawiera dużą liczbę plików w stanie fragmentacji to wtedy program defragmentujący może pracować godzinami. Defragmentacja serwera powinna być wykonywana poza godzinami pracy. Zablokowane pliki użytkowników dodatkowo utrudniają pracę programu defragmentującego. Czas potrzebny na przeprowadzenie defragmentacji zależy od prędkości operacji zapisu/odczytu (I/O speed), jednostki centralnej oraz magistrali systemowej.Na zakończenie Disk Defragmenter wyświetla nową analizę stanu fragmentacji woluminu w postaci graficznej i nowy raport. W przypadku woluminu o dużej liczbie plików wymagających defragmentacji konieczne może być wielokrotne uruchamianie procedury defragmentacji tego woluminu.Defragmentacja woluminów FAT i FAT32

Do przeprowadzania defragmentacji woluminów FAT i FAT32 służy ta sama konsola Disk Defragmenter (Defragmentacja dysku), co dla woluminów NTFS. Jednak program, który się za nią kryje, Dfrgfat, jest inny. W przypadku komputera z wyborem systemu operacyjnego przy uruchomieniu (dual-boot machine) do defragmentacji woluminów FAT i FAT32 systemu Windows 2000 można użyć programu z Windows 9x lub innego dostępnego na rynku.

Zasadniczo systemy plików FAT i FAT32 są bardziej wrażliwe niż NTFS, więc użytkownik może napotykać problemy podczas defragmentacji tych systemów. Dobrym zwyczajem jest „oczyszczenie” dysku przed defragmentacją za pomocą programu Chkdsk. I, jak zawsze, trzeba się upewnić, czy istnieje dobra kopia zapasowa (backup).

Defragmentacja — podsumowanie

Oto najważniejsze informacje dotyczące programu Disk Defragmenter (Defragmentacja dysku):

Przed defragmentacją należy usunąć stare pliki uruchamiając program Chkdsk.
Disk Defragmenter (Defragmentacja dysku) stosuje się do wszystkich systemów plików Windows 2000. Defragmentację systemu plików FAT/FAT32 wykonuje program DFRGFAT, a systemu NTFS — program DFRGNTFS.
Procedura defragmentacji wykorzystuje do przenoszenia plików wywołania interfejsu API systemu Windows 2000. Dla zachowania integralności systemu plików wywołania podlegają ochronie plików systemowych, zapisując wykonywane operacje do dziennika zdarzeń (transaction logging) i dziennika zmian (Change Journal).
Defragmentacji nie podlegają pliki stronicowania, pliki Rejestru i inne zablokowane pliki systemowe.
Aby całkowicie usunąć fragmentację często używanego foldera, może być konieczne wielokrotne wykonywanie defragmentacji.
--> Procedura defragmentacji nie powinna być uruchomiona jako zadanie zaplanowane[Author:UP] .

Ograniczenia obszaru dysku nakładane na użytkowników

Słabością Windows NT jest brak możliwości podzielenia pojemności dysku twardego pomiędzy użytkowników. Użytkownik może przechowywać w katalogu domowym na serwerze Windows NT pocztę elektroniczną z okresu 3 lat, a administrator może jedynie narzekać i słać ostrzeżenia. Dostępne są narzędzia programowe spoza systemu dla Windows NT, pozwalające na przydzielanie zasobów dyskowych poszczególnym użytkownikom, ale administratorzy systemu od dawna domagali się narzędzi zintegrowanych do kompleksowego zarządzania nakładaniem ograniczeń na użytkowników. Windows 2000 próbuje spełnić te żądania poprzez usługę przydzielania użytkownikom zasobów dyskowych (Quota Management service).

Napisałem „próbuje”, bo sposób, w jaki zaimplementowano tę usługę w Windows 2000, nie jest optymalny pod względem wydajności systemu. W razie zastosowania tego narzędzia może okazać się, że konieczna jest znaczna zmiana ustalonych procedur postępowania administratora. Może również zapaść decyzja, że nadszedł czas, aby kupić jedno z wielu narzędzi dostępnych na rynku. Przyjrzyjmy się więc sposobowi implementacji usługi przydzielania zasobów dyskowych i jej niedostatkom.

Opis funkcjonalny usługi ograniczania obszaru dysku dla użytkowników

System plików NTFS zawsze zawierał rekord metadanych $Quota, z tym, że ten rekord nie był wykorzystywany przed pojawieniem się Windows 2000. Rekord $Quota zawiera dwa pola określone przez dwa strumienie (streams) $Index_Root. W pierwszym z nich, $O, zapisane są identyfikatory bezpieczeństwa (SID) właścicieli plików. Poniżej przedstawiono przykładowy wydruk tego pola dla 2 użytkowników.

<<koniec atrybutu $File_Name rekordu $Quota>>

26000020 00000000 06032400 51007500 &.. ......$.Q.u.

6F007400 61000000 o.t.a....

<<początek atrybutu $Index_Root zwanego $O zawierającego pozycje z danymi właścicieli>>

90000000 D8000000 ......

00021800 00000300 B8000000 20000000 ............ ...

24004F00 00000000 00000000 11000000 $.O.............

<<SID użytkowników zaznaczone pogrubioną czcionką. Podkreślone bajty w SID to identyfikator względny (relative ID-RID) w zapisie szesnastkowym. Przekształcając na postać dziesiętną otrzymujemy RID pierwszego użytkownika równy 1113, a drugiego 1122.

Ostatnia podkreślona liczba w każdej pozycji to numer kolejny użytkownika. Aby pierwszy użytkownik miał dostęp do woluminu z przypisanymi ograniczeniami obszaru dostępnego dla użytkowników, lub by można mu było przydzielić taki obszar, otrzymuje numer 0101, drugi użytkownik otrzymuje numer 0201 itd.>>

2C000400 00000000 30001C00 00000000 ,.......0.......

01050000 00000005 15000000 5B40E770 ............[@.p

F03CDC64 4F65AB2E 59040000 01010000 .<.d0e..Y.......

2C000400 00000000 30001C00 00000000 ,.......0.......

01050000 00000005 15000000 5B40E770 ............[@.p

F03CDC64 4F65AB2E 62040000 02010000 .<.d0e..b.......

Drugi strumień (index stream), $Q, zawiera domyślne wartości ograniczeń, wartości progowe i takie atrybuty jak Deny Disk Space lub Log Event. Kiedy użytkownik ma nałożone ograniczenia obszaru dysku lub dopisuje pliki do woluminu, w którym takie ograniczenia są aktywne, jego identyfikator bezpieczeństwa SID zostaje dodany do pola $O i wtedy z pola $Q można odczytać wartości graniczne dla tego użytkownika.

<<Nagłówek pola $Q>>

90000000 B0010000 00021800 00000200 ................

90010000 20000000 24005100 00000000 .... ...$.@.....

<<Znaczniki i ustawienia dla ograniczeń. Pierwsza liczba zapisana czcionką --> pogrubioną[Author:UP] jest to domyślna wartość progowa. Drugi numer jest domyślną wartością graniczną dostępnego rozmiaru dysku. Podkreślona liczba zawiera znaczniki atrybutu.>>

00000000 10000000 00100000 08000B00 ................

10000000 80010000 80010000 00000000 ................

14003000 00000000 48000400 00000000 ..0.....H.......

01000000 02000000 71000000 00000000 ........q.......

00000000 E0D12BF8 00C7BE01 00100E00 ......+.........

00000000 00A00F00 00000000 00000000 ................

<<Pozycje dotyczące użytkowników. Pierwsza liczba, zapisana czcionką pogrubioną, jest wartością progową dla danego użytkownika. Druga wyróżniona liczba jest to ograniczenie górne obszaru dysku dla tego użytkownika. Ostatnia linia zawiera identyfikator bezpieczeństwa (SID) użytkownika.

14004C00 00000000 60000400 00000000 ..L..... .......

01010000 02000000 00000000 00000000 ................

00000000 806C548A 02C7BE01 00C01200 .....lT.........

00000000 00401F00 00000000 00000000 .....@..........

00000000 01050000 00000005 15000000 ................

5B40E770 F03CDC64 4F65AB2E 59040000 [@.p.<.dOe..Y...

14004C00 00000000 60000400 00000000 ..L..... .......

02010000 02000000 00000000 00000000 ................

00000000 80D9DCE2 02C7BE01 00100E00 ................

00000000 1F850F00 00000000 00000000 ................

00000000 01050000 00000005 15000000 ................

5B40E770 F03CDC64 4F65AB2E 62040000 [@.p.<.dOe..b...

Jeśli ograniczenia są aktywne, system ustawia bit Quota w polu atrybutu $Standard_Information każdego pliku i zapisuje tam również rozmiar pliku. Atrybut $Standard_Information jest rezydentny, umożliwia więc Menedżerowi ograniczeń szybkie przeszukiwanie tablicy MFT, aby wskazać obszar dysku przyporządkowany każdemu z użytkowników.

Wady usługi ograniczania obszaru dysku dla użytkowników

Taka metoda zastosowania rekordu metadanych $Quota jest przyczyną wad usługi nakładania ograniczeń obszaru dysku na poszczególnych użytkowników:

Ograniczenia są przypisane do woluminu. Nie można przypisać ich do katalogu. To wpływa na sposób podziału obszaru zajmowanego przez katalog. Jeśli do woluminu zawierającego pliki z dwóch działów będzie przypisane ograniczenie 100 MB, to obszar dysku dostępny dla użytkowników pracujących w obydwu działach jest ograniczony do tychże 100 MB.
Ograniczenia są przypisane właścicielom plików. Nie można użyć tej usługi do podzielenia obszaru dysku pomiędzy grupy. Np. działowi wzornictwa przemysłowego nie można przydzielić większego obszaru na dysku niż działowi sprzedaży, pomimo że plastycy potrzebują dużo więcej miejsca do przechowywania plików. Jeśli administrator chce przechowywać pliki członków grupy Dział Wzornictwa w tym samym woluminie, gdzie zapamiętywane są pliki członków innych grup, musi przydzielić większe zasoby dyskowe poszczególnym członkom tej grupy.
Członkowie grupy Administrators nie podlegają ograniczeniom. Grupa Administrators jest wolna od ograniczeń. Będąc administratorem można uzyskać status właściciela pliku stosując kilka sprytnych sposobów, np. odtwarzając plik z taśmy do katalogu innego niż katalog, z którego pochodził. Kopiując pliki użytkowników do innego serwera, gdzie jest więcej miejsca, także można uzyskać status właściciela.
Parametry ograniczeń obszaru dysku są częścią systemu plików, a nie Rejestru. Ustawienia te przenoszone są razem z dyskiem do innego komputera z Windows 2000. Po przełożeniu dysku do komputera z Windows NT, Service Pack 4 lub nowszy, a także w przypadku komputera z wyborem systemu operacyjnego przy starcie (dual-boot machine) jest dostęp do woluminu z systemem plików NTFS5, ale ograniczenia obszaru dysku nie działają. Zapis danych na dysk przez Windows NT 4 może zniszczyć dane dotyczące ograniczeń.
Ograniczenia uwzględniają wyliczony rozmiar pliku, a nie rzeczywisty rozmiar pliku zapisanego na dysku. W przypadku plików skompresowanych lub plików „rzadkich” (sparse files), użytkownik może borykać się z trudnościami ze względu na ograniczenie obszaru dysku, mając w rzeczywistości jeszcze do dyspozycji sporo miejsca na dysku.
Obsługa ograniczeń wpływa na wydajność systemu. Firma Microsoft nie opublikowała żadnych statystyk wydajności porównujących działania na plikach i drukowanie bez nałożonych ograniczeń oraz z ich wykorzystaniem. Testy laboratoryjne wykonane przez autora wykazały taki wpływ, ale brak jest danych ilościowych, które można uzyskać stosując NetBench lub ServerBench. Fakt, że system musi aktualizować wskaźnik użycia plików w woluminie, powinien być wskazówką, że następuje obniżenie wydajności. Należy o tym pamiętać podejmując decyzję o zastosowaniu ograniczeń obszaru dysku aktywnych przez cały czas. Aby uniknąć spowolnienia pracy systemu, można okresowo włączać i wyłączać sprawdzanie ograniczeń.

Należy zalogować się na konto z uprawnieniami administratora. Do uruchomienia konsoli „Zarządzanie ograniczaniem obszaru dysku” (Quota Management) z uprawnieniami administratora nie można wykorzystywać usługi Secondary Logon Service (polecenie Runas).

Nadawanie statusu właściciela pliku z wykorzystaniem narzędzi spoza systemu Windows 2000

Standardowe narzędzia Windows 2000 dotyczące bezpieczeństwa systemu zezwalają tylko na przejmowanie własności pliku, a nie na nadawanie.

Do przypisania użytkownikowi własności pliku można użyć następujących narzędzi:

Setowner firmy Pedestal Software (www.pedestalsoftware.com), część pakietu narzędzi pod nazwą NTSecTools

Chown firmy MKS Software (www.mks.com), z pakietu MKS Toolkit

Narzędzia z pakietu MKS Toolkit mają postać podobną do Unixowych z oprogramowania „Services for Unix” firmy Microsoft.

Opis procedury nakładania ograniczeń obszaru dysku (Quota Management)

Kolejne kroki opisane poniżej pozwalają na przyporządkowanie ograniczeń do woluminu przechowującego tylko katalogi domowe użytkowników. Podaje się dwa parametry: wartość początkową (threshold) i górną granicę. Przekroczenie przez użytkownika jednej z tych wartości powoduje wpisanie ostrzeżenia do dziennika zdarzeń (Event Log). Można również zapobiec zapisywaniu przez użytkowników plików przekraczających swoim rozmiarem ograniczenie górne obszaru dysku. Trzeba bacznie przyglądać się ostrzeżeniom w dzienniku zdarzeń, ponieważ pojawiają się jako informacje (niebieska kropka), a nie jako ostrzeżenia (żółta lub czerwona kropka).

Procedura 13.8 Nakładanie ograniczeń obszaru woluminu dostępnego dla użytkowników

Otwórz Exploratora. Prawym klawiszem myszy kliknij na ikonie odpowiedniego dysku, wybierz opcję Właściwości (Properties), a następnie zakładkę Quota (patrz rys.13.12). Operacje na woluminie dołączonym dokonuje się po wybraniu go poprzez konsolę Disk Management.

0x01 graphic

Rysunek 13.12. Okno Volume Properties (Właściwości woluminu) pokazuje wartości ograniczeń dla katalogów domowych użytkowników.

Domyślnie ograniczenia nie są aktywne. Wybierz opcję Enable quota management (Stosowanie ograniczeń — zezwolenie) załączając działanie ograniczeń dla tego woluminu.
Zaznacz opcję Deny disk space to users exceeding Quota limit. Można na razie pominąć tę opcję, aby uzyskać informacje o użytkownikach przekraczających podane wartości ograniczeń pozwalające ustalić razem z nimi, które pliki można przenieść lub skasować przed wprowadzeniem ograniczeń.
Zaznacz opcję Limit disk space to i wprowadź rozmiar obszaru dysku dostępnego dla użytkownika i wartość progową, po przekroczeniu której wysyłane jest ostrzeżenie. System zaokrągla podane wartości, uwzględniając rozmiar jednostki alokacji. Z tej przyczyny w powyższym przykładzie wartość graniczna wynosi 0,.97 GB zamiast wpisywanej wartości 1000 MB.
Zaznacz obydwie opcje zapisywania komunikatów. W Dzienniku Aplikacji (Application Log) zapisane będą informacje o użytkownikach przekraczających wprowadzone ograniczenia.
Naciśnij Apply (Zastosuj). System wyświetli ostrzeżenie o tym, że dysk będzie sprawdzany w celu uaktualnienia wskaźników użycia dysku.
Naciśnij OK, aby uaktywnić ograniczenia w danym woluminie. System przeszukuje tablicę MFT i ustawia bity ograniczenia w rekordach plików oraz odczytuje informacje o właścicielach plików. Po zakończeniu przeszukiwania naciśnij Quota Entries. Otworzy się okno — patrz rys. 13.13. Przetworzenie przez system identyfikatorów bezpieczeństwa (SID) na nazwy użytkowników może trochę potrwać, co jest stanem normalnym, a nie wskaźnikiem problemów z Active Directory, o ile nazwy te w końcu się pojawią. Gdyby nazwy nie pojawiły się, należy poszukać, jaki problem wystąpił, komunikując się z serwerem Global Catalog.

0x01 graphic

Rysunek 13.13. Okno Quota Entries (Ograniczenia). Pokazano konto BUILTIN\Administrators z nieograniczonym dostępem do dysku oraz konto użytkownika z podanymi wartościami ograniczeń i wskaźnikami wykorzystania.

Po otwarciu okna Quota Entries (Ograniczenia) bezpośrednio po wprowadzeniu ograniczeń jedyną pozycją w tabeli będzie grupa lokalna Administrators. Użytkownicy nie pojawią się na liście dopóty, dopóki nie będą korzystać z dysku. Rys. 13.13 przedstawia przykładowe dane dla grupy Administrators oraz dla użytkownika o nazwie USER110. Uwagę zwraca brak ograniczeń dla grupy Administrators. Ograniczenia obszaru dysku dla użytkownika USER110 przyjęły wartości domyślne.
Jeśli jest konieczna zmiana ograniczeń dla któregoś z użytkowników, można dopisać nową nazwę użytkownika do listy w oknie Quota Entries (Ograniczenia) lub wybrać z tej listy nazwę użytkownika, który już miał dostęp do woluminu. Z menu wybierz pozycję Quota (Ograniczenia)|New Quota Entry (Nowe ograniczenia). Pojawi się okno Select Users (Wybierz użytkowników).
Wybierz użytkownika lub użytkowników, którzy mają mieć nałożone indywidualne ograniczenia obszaru woluminu. Można wybrać użytkowników z domen zaufanych. Jeśli nie wprowadzono specjalnych ograniczeń dla użytkowników zdalnych, podlegają oni ograniczeniom z wartościami domyślnymi.
Aby dodać nazwę użytkownika do listy ograniczeń naciśnij przycisk Add (Dodaj), a następnie zapamiętaj zmiany naciskając przycisk OK. Otworzy się okno Add New Quota Entry (Dodaj nowe ograniczenia), rys. 13.14.

--> Rysunek 13.14[Author:UP] . Add New Quota Entry (Dodaj nowe ograniczenia). Powiększenie obszaru woluminu w stosunku do wartości domyślnych dla wybranego użytkownika.

Można wprowadzić nowe wartości ograniczeń lub znieść ograniczenia całkowicie. Aby zapisać zmiany i powrócić do okna Quota Entries (Ograniczenia), naciśnij przycisk OK. Na liście pojawi się nazwa użytkownika z nowymi ograniczeniami i aktualnym statusem.
Zmiany dla wielu użytkowników można wprowadzić jednocześnie, wykorzystując znany z Windows sposób zaznaczania przy pomocy klawisza Control. Następnie z menu należy wybrać opcję Quota (Ograniczenia)|Properties (Właściwości).

Narzędzia pozasystemowe do wprowadzania ograniczeń obszaru woluminu

Jeśli okaże się, że usługa nakładania ograniczeń obszaru dysku Windows 2000 nie spełnia twoich potrzeb, możesz spróbować któregoś z narzędzi dostępnych na rynku.

Najczęściej używanymi programami dla Windows NT są: QuotaAdvisor firmy Quinn Software, dostępny pod adresem www.sunbelt-software.com, oraz QuotaServer for NT firmy Northern Technologies, Szwecja, dostępny pod adresem www.northern.se. Obydwa narzędzia pracują pod kontrolą systemu Windows 2000.

Eksportowanie i importowanie ograniczeń pomiędzy komputerami

Administrator nie ma możliwości centralnego wprowadzania ograniczeń. W celu nałożenia ograniczeń na użytkowników w całej domenie, trzeba dokonać eksportu i importu ustawień pomiędzy komputerami tej domeny. Można tego dokonać tylko w obrębie jednej domeny, w przeciwnym razie komputer docelowy nie rozpozna identyfikatorów bezpieczeństwa (SID).

Procedura 13.9 Import i eksport ograniczeń pomiędzy komputerami

Wybierz zakładkę Quota (Ograniczenia) w oknie Properties (Właściwości) tego woluminu, którego wartości ograniczeń mają być eksportowane.
Naciśnij przycisk Quota Settings (Ustawienia ograniczeń). Otworzy się okno Quota Settings (Ustawienia ograniczeń).
Z menu wybierz Quota (Ograniczenia)|Export (Eksportuj). Otwory się okno Quota Export (Eksportuj ograniczenia).
Nadaj nazwę plikowi ustawień i wybierz katalog, w którym ma być zapisany. Plik jest zapamiętywany w specjalnym formacie.
W komputerze, do którego ustawienia ograniczeń mają być importowane, otwórz okno Quota Settings (Ustawienia ograniczeń).
Z menu wybierz Quota (Ograniczenia)|Import (Importuj). Potwierdzenie polecenia spowoduje zapisanie ustawień ograniczenia obszaru woluminu w komputerze docelowym. Lista statusu pokaże teraz nowe ustawienia dla poszczególnych użytkowników.

Usuwanie użytkowników z listy ograniczeń

Nie można po prostu skasować użytkownika z listy ograniczeń. Identyfikator bezpieczeństwa użytkownika (SID) jest związany z plikiem. To powiązanie musi być przerwane, zanim system zezwoli na skasowanie ustawień dla użytkownika. Alternatywnym rozwiązaniem jest przeniesienie własności pliku użytkownika na administratora lub innego użytkownika za pomocą pozasystemowego programu narzędziowego. Można również skasować pliki użytkownika, o ile jest to rozwiązanie skuteczne.

Kiedy administrator przystępuje do usuwania użytkownika, wyświetlana jest lista plików, których właścicielem jest ten użytkownik, znajdujących się na wybranym woluminie; patrz rys. 13.15. Wykorzystując polecenia dostępne w tym oknie administrator może podjąć dowolne działanie, odpowiednie do pozbawienia wybranego użytkownika własności plików.

Rysunek 13. --> 15. Wykaz plików na wybranym woluminie, których właścicielem jest usuwany użytkownik.[Author:E]

Po ubezwłasnowolnieniu użytkownika można usunąć z listy ograniczeń dotyczące go ustawienia. Jeśli dokonuje się tego wykorzystując okno Disk Quota (Ograniczenia), użytkownik zostaje usunięty z listy po naciśnięciu przycisku OK.

Najważniejsze zagadnienia związane z usługą ograniczania obszaru dysku dostępnego dla użytkowników

Po wprowadzeniu ograniczeń administrator musi uporać się z pytaniami i frustracjami użytkowników. Ponieważ ograniczenia są przypisane do całego woluminu, mogą wprawiać użytkowników w zakłopotanie na kilka sposobów:

W przypadku istnienia wielu udostępnionych (współużytkowanych) katalogów na tym samym woluminie, użytkownik może podjąć próbę kopiowania plików z jednego mapowanego dysku do drugiego. Pytanie skierowane do administratora systemu będzie brzmiało mniej więcej tak: „Próbuję skopiować moje sprawozdanie miesięczne z dysku K na dysk L, ale pojawia się błąd braku miejsca na dysku”. Można próbować tłumaczyć, że zarówno K, jak i L oznaczają ten sam wolumin i kopiowanie pliku o rozmiarze 30 MB przekracza ograniczenia obszaru woluminu nałożone na użytkownika. Lepszym rozwiązaniem jest usunięcie nadmiarowych udziałów (share points).
Jeśli jeden wolumin zawiera pliki systemowe i pliki użytkownika, zadanie drukowania z buforowaniem może przekroczyć nałożone ograniczenia. W tym przypadku komunikat o błędzie jest niejasny, jak zresztą większość komunikatów o błędach drukarki, a tym samym trudny do zdiagnozowania. Rozwiązaniem jest przechowywanie osobno plików systemowych i plików użytkowników, przy czym na wolumin systemowy nie nakłada się ograniczeń.
Szeroko stosowany jest taki sposób konfigurowania komputerów stojących w miejscach publicznych (walk-up workstations, kiosk machines), by użytkownicy mogli odbierać pocztę elektroniczną i zapisywać kontrolki czasu do pliku. Pliki te zapisywane są na dyskach lokalnych tych komputerów. Można wprowadzić ograniczenia obszaru dostępnego dla użytkowników na dysku lokalnym, ale trzeba zwracać uwagę na profile wędrujące. Jeśli użytkownik przekroczy ograniczenia, system odmówi załadowania profilu wędrującego użytkownika. Nie zezwoli także na stworzenie nowego profilu z wykorzystaniem pliku NTUSER.DAT z domyślnego profilu użytkownika. Użytkownik nie może się zalogować. To wcale nie musi być złe, biorąc pod uwagę, że użytkownik naruszył obowiązujące zasady przekraczając przydzielone mu zasoby, ale zawsze konieczna jest interwencja administratora.
Należy pamiętać, że prawo własności pliku przenosi się wraz z plikiem. To oznacza, że użytkownik wykraczający poza nałożone ograniczenia zasobów może przenosić pliki z innych miejsc, o ile nie jest ich właścicielem, ale nie może kopiować plików, ponieważ staje się właścicielem tego skopiowanego pliku. Zwykle powoduje to niekończące się kłopoty.
Użytkownikowi wykraczającemu poza nałożone ograniczenia zasobów, próbującemu zapisać plik na dysku, sygnalizowany jest błąd „Dysk pełny” (Disk full). Konsekwencje są nieokreślone. Rozumni użytkownicy mogą zapisać plik na dysku lokalnym lub na innym udostępnionym dysku sieciowym. Jeśli tego nie zrobią, zmiany mogą zostać utracone w czasie, gdy będą próbować zrozumieć, dlaczego nie da się zapisać pliku. System nie wysyła ostrzeżeń w przypadku przekroczenia przez użytkownika wartości progowej, można skonfigurować alarm dla administratora.

--> Brakuje tekstu ze strony 895:

Wskazówek dotyczących Ograniczeń i zarządzenia plikami, oraz podsumowania tematu.[Author:E]

Usługi zdalnego przechowywania danych (Remote Storage Services)

Przechowywanie danych jest oceniane według trzech kryteriów: koszt, łatwość dostępu i wydajność. Nośnikiem danych o najwyższym koszcie, największej łatwości dostępu do danych i największej wydajności są stałe dyski twarde. Nośnikiem danych o najniższym koszcie, najtrudniejszym dostępie do danych i najgorszej wydajności jest taśma.

Oto kilka cen. W końcu roku 1999 dysk 50 GB SCSI można było kupić za cenę poniżej 2000 dolarów. Daje to cenę niższą niż 4 centy za megabajt, chociaż, po doliczeniu dodatkowych wydatków, koszt rzeczywisty jest bliższy 10 centom. Nawet przy tak niskich cenach przechowywanie danych dużej firmy, powiedzmy 50 TB, przy zachowaniu natychmiastowego dostępu do danych, kosztuje ponad 5 milionów dolarów, nie licząc wydatków na konserwację i archiwizację danych.

Napęd taśmowy (DLT unit), na którym można zapisać 3 TB danych kosztował 75000 dolarów, co daje cenę 2,3 centa za megabajt. Przechowywanie tych samych 50 TB danych kosztowałoby 1,2 miliona dolarów. Ale dostęp do plików na taśmie jest wolny i niewygodny.

Technologia łącząca tanie przechowywanie danych na taśmie z szybkością działania i wygodą systemu plików nosi nazwę hierarchicznego przechowywania danych (Hierarchical Storage Management — HSM). Usługa HSM przenosi stare pliki na taśmę, gdzie znajdują się w stanie gotowości do przeniesienia z powrotem na dysk, gdyby ktoś ich potrzebował. Zasada działania HSM pochodzi z komputerów klasy mainframe, gdzie była stosowana od dawna. Jednak w przypadku komputerów osobistych HSM nie znalazła większego zastosowania, ponieważ ceny dysków są niskie, a prowadzenie dużych bibliotek na taśmach jest kłopotliwe.

Ostatnie osiągnięcia robotyki sprawiły, że zautomatyzowane biblioteki danych na taśmach mogą mieć zastosowanie w działach informatyki średniej wielkości. Nikt nie przepuszcza okazji wyposażenia systemu operacyjnego w nowe możliwości, więc firma Microsoft zleciła firmie Highground Technologies, www.highground.com, wykonanie wersji HSM dla Windows 2000, wykorzystującej zalety takich tanich rozwiązań bibliotek taśmowych.

Wynikiem tego kontraktu są usługi zdalnego przechowywania danych (Remote Storage Service — RSS). Nie należy mylić usługi RSS z usługą Removable Storage Mangement (RSM). System za pomocą usługi RSM steruje bibliotekami danych na różnych nośnikach, takich jak taśmy i CD-ROM-y. RSS wykorzystuje RSM do wprowadzania i wyprowadzania nośnika z biblioteki oraz do ściągania nośnika z zewnętrznej składnicy danych. Usługa RSS jest dostępna w systemach Windows 2000 Server i Advanced Server, nie ma jej w wersji Windows 2000 Professional.

Dodatkowe możliwości HSM

Tak jak większość firm dostarczających dodatkowe elementy systemu Windows 2000, Highground oferuje za dodatkową opłatą bardziej rozbudowany pakiet programowy do zarządzania bibliotekami. Wersję testową można skopiować z firmowej strony WWW.

Opis funkcji usług RSS

Usługi RSS przyjmują dwa kryteria oceny, czy plik powinien być przesunięty na taśmę: data ostatniego dostępu do pliku i rozmiar żądanego wolnego obszaru woluminu. Kiedy obciążenie woluminu przekroczy wartość progową podaną przez administratora, RSS przerzuca najstarsze pliki na taśmę szybciej, niż inwestor redukuje koszty po wrogim przejęciu firmy.

Usługi RSS wykorzystują dynamiczne wskaźniki lokalizacji danych (reparse points) do informowania systemu plików o położeniu aktualnie niewykorzystywanych plików (offline files). Kiedy użytkownik korzysta z jakiegoś pliku zapisanego na taśmie, usługi RSS przesyłają plik z taśmy z powrotem na dysk, gdzie już jest obsługiwany przez standard NTFS. To może potrwać dłuższą chwilę, więc system, aby umilić czas oczekiwania na zakończenie pracy podsystemu taśmowego, wyświetla zabawną, animowaną ikonę. Nazwa usługi zdalnego przechowywania danych (Remote Storage Services — RSS) dlatego występuje w liczbie mnogiej, ponieważ w rzeczywistości jest to zestaw czterech usług pracujących wspólnie nad obsługą hierarchicznego przechowywania danych (HSM). Ten zestaw jest ładowany przez SVCHOST. Pozycje Rejestru znajdują się w kluczu HKLM|System|CurrentControlSet|Services. Wymienione wyżej usługi to:

Moduł programowy Remote Storage Engine — RsEng.exe. Koordynuje różne usługi i stanowi interfejs dla konsoli administratora RsAdmin.msc.

Agent systemu plików zdalnego przechowywania danych (Remote Storage File System Agent — RsFSA). Jest to filtr systemu plików, który działa jako pośrednik systemu zdalnego przechowywania plików.

Podsystem zdalnego przechowywania danych (Remote Storage Subsystem — RsSub.exe). Steruje nośnikiem taśmowym.

Połączenie użytkownika zdalnego przechowywania plików (Remote Storage User Link — RsFSA). Działa jako interfejs klienta. Dwa programy pomocnicze, RsNotify i RsMover, a także kilkanaście bibliotek DLL, również mają przedrostek Rs.

Usługi RSS przechowują informacje o plikach zdalnych w dwóch systemowych bazach danych (Microsoft Jet databases) w katalogu \WINNT\System32\RemoteStorage.

Moduł programowy (database engine) EngDB, śledzi lokalizację plików w systemie taśmowym.

Baza danych Agenta systemu plików, FsaDB, śledzi pliki zdalne na dysku.

Pliki zbiorcze w katalogu \RemoteStorage przechowują rekordy przed odesłaniem ich do głównej bazy danych.

Uwagi dotyczące działania usług RSS

Oto kilka uwag mających wpływ na sposób wykorzystania usług RSS przez administratora:

Aplikacje czasami przeszukują pliki, otwierając je. Jedną z takich aplikacji jest niesławny FindFast. Jeśli aplikacja przeszukująca sięga do wielu plików zdalnych jednocześnie, może zasypać system odwołaniami, a o ile taka aplikacja nie zostanie zablokowana, może zajść konieczność zatrzymania jej działania za pomocą Menedżera zadań (Task Manager) lub polecenia Kill. Nie każde przeszukiwanie pliku kończy się przywołaniem. Tak długo, jak przeszukiwanie dotyczy tylko atrybutów lub znaczników w części rezydentnej atrybutu, sam plik nie jest otwierany. Indeksowanie kontekstowe (context indexing) oraz poszukiwanie łańcucha znaków (full text search) są zablokowane w przypadku plików zdalnych.

Jako nośnik danych „offline” nie można stosować przenośnych nośników danych jak Zip i Jaz, dysków magnetooptycznych i CD-ROM-ów. Musi to być taśma. Jeśli jeszcze nie dokonano instalacji napędu taśmy, instrukcja zawarta jest w rozdziale 2.

Jeśli w komputerze jest tylko jeden napęd taśmy, trudności sprawi koordynacja wykonywania kopii zapasowych systemu i usług RSS. Jeśli istnieje tylko jeden serwer lub nie ma możliwości robienia kopii zapasowych na stacji roboczej, to wyjściem z tej sytuacji jest rezygnacja ze stosowania RSS lub zainstalowanie drugiego napędu taśmy.

W przypadku braku biblioteki taśm należy ograniczyć liczbę plików zdalnych, aby zmieściły się na jednej kasetce, albo przygotować się na ręczną wymianę kaset w trakcie pracy, gdy użytkownicy będą sięgać do plików zdalnych. W przypadku, gdy pliku zdalnego nie można zlokalizować w bibliotece, pojawi się komunikat dla użytkownika „Skontaktuj się administratorem systemu”.

Należy upewnić się, czy program antywirusowy jest wystarczająco inteligentny, by wykonać swoją pracę bez zmiany daty ostatniego dostępu do pliku (Last Acces Data). W przeciwnym razie usługi RSS nie przeniosą żadnego pliku na taśmę.

Usługi RSS nie są zamiennikiem wykonywania kopii zapasowych. Taśmy mogą stać się nieczytelne lub katalog może być uszkodzony. Jeśli zachodzi konieczność ponownego zainstalowania Windows 2000 w systemie zawierającym pliki zdalne, administrator jest zmuszony odtworzyć wolumin pierwotny, odzyskać bazy danych zdalnego przechowywania (Remote Storage databases) oraz dołączyć ponownie taśmy, zanim będzie można korzystać z plików zdalnych. Więcej szczegółów w dalszej części niniejszego rozdziału, w paragrafie --> „Tworzenie kopii zapasowych plików zdalnych”.[Author:PGon]

Wstępna konfiguracja usług RSS

Wykonanie kolejnych kroków opisanych w tym paragrafie powoduje załadowanie sterowników RSS i przygotowanie taśmy do przechowywania plików zdalnych.

Sterowniki RSS nie są instalowane standardowo w Windows 2000. Potrzebny jest dysk Server CD. Instalacja wymaga ponownego uruchomienia komputera.

Procedura 13.10 Wstępna konfiguracja usług RSS

Otwórz Panel Sterowania|Dodaj/Usuń programy|Instalator systemu Windows (Control Panel|Add/Remove Programs|Windows Components).
Wybierz opcję Zdalne przechowywanie plików (Remote Storage) i naciśnij przycisk Dalej (Next). System zainstaluje sterowniki i dokona odpowiednich zmian w Rejestrze. Po zainstalowaniu usługi należy ponownie uruchomić system. Załadowana zostaje konsola Zarządzanie zdalnym przechowywaniem plików (Remote Storage Management), Rsadmin.msc, która służy do zarządzania usługami RSS.
Po ponownym uruchomieniu otwórz konsolę zdalnego przechowywania plików poprzez opcje START|PROGRAMS|ADMINISTRATIVE TOOLS|REMOTE STORAGE. Przy pierwszym uruchomieniu konsoli po zainstalowaniu usług RSS pojawi się kreator, który pomoże w konfigurowaniu usług RSS.
W oknie powitania naciśnij Dalej (Next). Kreator sprawdzi przywileje administratora i obecność nośnika odpowiedniego do zdalnego przechowywania plików, następnie otworzy okno Zarządzanie woluminem (Volume Management). Zobacz rys. 13.16.

--> Brak rysunku.[Author:E]

Rysunek 13.16. Kreator usługi zdalnego przechowywania plików (Remote Storage Setup Wizard) — okno Zarządzanie woluminem (Volume Management), przedstawiające wybór katalogu domowego użytkownika jako dysku, dla którego konfigurowane są usługi RSS.

Wybierz odpowiedni dysk. Nie należy wybierać dysku systemowego/startowego. Jeśli wybrany wolumin zawiera katalogi dołączania, to pliki z woluminów dołączonych nie są przenoszone.
Naciśnij Dalej (Next). Pojawi się okno Ustawienia woluminu (Volume Settings) (Zobacz rys. 13.17). Wartość Desired Free Space (Żądany obszar wolny) określa, kiedy usługi RSS zaczną przenoszenie plików. Wartością domyślną jest 5%. Większy komfort pracy zapewnia ustawienie tej wartości na 20%. Ta wartość powoduje pozostawienie na dysku odpowiedniego miejsca dla wielkich plików ściąganych z powrotem z taśmy. Można zwiększyć minimalny rozmiar pliku. Należy pamiętać, że 1000 małych plików zajmuje dużą część obszaru dysku, zwłaszcza w przypadku dużego rozmiaru jednostek alokacji.

--> Brak rysunku.[Author:E]

Rysunek 13.17. Kreator usługi zdalnego przechowywania plików (Remote Storage Setup Wizard) — okno Ustawienia woluminu (Volume Settings).

Naciśnij Dalej (Next). Pojawi się okno Rodzaj nośnika (Media Type). W przypadku kilku systemów taśmowych, zainstalowanych na serwerze, można wybrać ten, który ma być wykorzystywany przez usługi RSS. Przykład przedstawia ustawienia dla taśmy typu DAT.
Naciśnij Dalej (Next). Otworzy się okno Plan kopiowania plików (Schedule for Copying Files). Kopiowanie plików domyślnie będzie odbywać się codziennie o godzinie 2:00. Ustawienie to można zmienić, jeśli kopiowanie plików zdalnych zbiega się z czasem wykonywania kopii zapasowej lub przenoszenie plików na taśmę ma odbywać np. tylko w weekendy. Okres i czas startu kopiowania plików na taśmę można zmienić naciskając Zmiana planu (Change Schedule). Można ustawić jednocześnie kilka procedur przenoszenia plików.
Naciśnij Dalej (Next). Pojawi się okno pokazujące listę dokonanych zmian.
Aby zaakceptować ustawienia, naciśnij Zakończ (Finish). System dokona zmian w Rejestrze i w systemie plików oraz inicjalizacji baz danych, a następnie otworzy konsolę zawierającą konsolę Zdalne przechowywanie plików (Remote Storage) i konsolę (Przechowywanie danych na nośnikach wymiennych) (Removable Storage).
Pozostaw konsolę otwartą i przejdź do następnego paragrafu.

Przydzielanie taśmy do puli nośników (RSS Media Pool)

W celu wykorzystania taśmy do zdalnego przechowywania plików, należy przydzielić taśmę do puli nośników (media pool) usług RSS za pomocą konsoli Removable Storage Management (Zarządzanie przechowywaniem danych na nośnikach wymiennych), co może wprawiać w zakłopotanie.

Jeśli napęd taśmy jest już używany przez Ntbackup lub inną aplikację spoza systemu Windows 2000 do wykonywania kopii zapasowych, taśma została przydzielona do aplikacji Backup. Rozszerzając strukturę drzewiastą Removable Storage (Przechowywanie danych na nośnikach wymiennych), w prawej części konsoli można znaleźć taśmę w gałęzi Backup.

Aby zachować zawartość tej taśmy, należy kliknąć prawym klawiszem myszy na nazwie nośnika i z menu wybrać opcję Eject (Wysuń). Kreator Eject Media (Wysuń nośnik) pozwoli na odzyskanie danych z taśmy. Następnie trzeba włożyć pustą taśmę i przygotować ją dla usług RSS.

Aby zapisać pliki zdalne na taśmie zawierającej kopię zapasową, najpierw trzeba usunąć przyporządkowanie taśmy do usługi Backup, a następnie przygotować ją jako nośnik wolny. Można to zrobić w następujący sposób:

Procedura 13.11 Zmiana przyporządkowania poprzednio używanego nośnika danych

Kliknij prawym klawiszem myszy na nazwie nośnika i z menu wybierz ALL TASKS (Wszystkie zadania)|DEALLOCATE (Zmiana przyporządkowania). Pojawi się ostrzeżenie przed utratą danych w wyniku podjętych działań.
Potwierdź ostrzeżenie naciskając Yes (Tak). Pojawi się kolejne ostrzeżenie, tylko po to, by upewnić się, że pierwsze ostrzeżenie zostało przeczytane. Potwierdź ostrzeżenie naciskając Yes (Tak). To zakończy proces usuwania poprzedniego przyporządkowania nośnika. W kolumnie State (Stan) pojawia się informacja Idle and Available (Wolny i dostępny).
Kliknij prawym klawiszem myszy na ikonie Media (Nośniki danych) i z menu wybierz opcję PREPARE (Przygotuj). To działanie przypisuje etykietę Nośnik Wolny (Free Media) i przenosi do puli nośników (pool). Pojawi się ostrzeżenie informujące o tym, że wszystkie dane na nośniku będą zniszczone.
Potwierdź ostrzeżenie naciskając Yes (Tak). Pojawi się prośba o potwierdzenie. Zakończ procedurę zmiany przyporządkowania nośnika naciskając Yes (Tak). System przenosi nośnik do ikony Tape (Taśma) w pozycji Free (Wolne).

Wybór plików do przechowywania w trybie offline

Usługi RSS są już uruchomione, a taśma czeka na zapisywanie plików. Teraz trzeba dokonać wyboru plików do przeniesienia na taśmę, zgodnie z procedurą opisaną poniżej. Rysunek 13.18 przedstawia układ początkowej konsoli Remote Storage (Zdalne przechowywanie plików).

--> Brak rysunku[Author:E] .

Rysunek 13.18. Remote Storage Setup Wizard (Kreator ustawień usług zdalnego przechowywania plików) —konsola Remote Storage (Zdalne przechowywanie plików).

Procedura 13.18 Wybór plików do przechowywania w trybie offline

Kliknij prawym klawiszem myszy na jednym z zarządzanych woluminów i z menu wybierz opcję INCLUDE|EXCLUDE RULES. Otworzy się okno Properties (Właściwości) zarządzanego woluminu. Do zmiany ustawień wprowadzonych za pomocą kreatora wykorzystaj zakładki General (Ogólne) oraz Settings (Ustawienia).
Naciśnij Add (Dodaj). Otworzy się okno Edit Include/Exclude Rule (Edycja reguł włączania i wyłączania). Zobacz rys. 13.19.

--> Brak rysunku[Author:E]

Rysunek 13.19. Okno Edit Include /Exclude Rule (Edycja reguł włączania i wyłączania).

Wprowadź rozszerzenie nazwy pliku, który ma być przeniesiony na taśmę lub pozostawiony na dysku twardym. Na przykład można wyłączyć przenoszenie na taśmę plików wykonywalnych i bibliotek DLL, lub przeciwnie, administrator chce, by przenoszone były tylko pliki z rozszerzeniem *.doc, *.xls oraz *.ppt. Zasady przenoszenia odczytywane są od góry do dołu, więc jeśli wpiszesz, że pliki *.doc z katalogu głównego woluminu mają znaleźć się na taśmie, a później wyłączysz pliki *.doc z określonego podkatalogu, to wtedy pierwszeństwo ma to pierwsze ustawienie.
Za pomocą myszy przesuń nośniki do ikony Tape (Taśma) w Remote Storage (Zdalne przechowywanie plików).
Zainicjuj ręcznie kopiowanie plików na taśmę klikając prawym klawiszem myszy na ikonie Managed Volume (Zarządzany wolumin) i wybierz opcję ALL TASKS (Wszystkie zadania)| COPY FILES TO REMOTE STORAGE (Kopiuj pliki na taśmę). Pojawi się okno z informacją wyjaśniającą, że nastąpiło utworzenie zadania do wykonania tej pracy. Więcej informacji poniżej.

Program Zaplanowane zadania (Task Scheduler) i usługi zdalnego przechowywania plików (RSS)

Podczas konfiguracji usług RSS do okresowego kopiowania plików powstaje skrypt, który jest przekazywany do programu Zaplanowane zadania (Task Scheduler). Status zadania można sprawdzić poprzez ikonę Zaplanowane zadania (Scheduled Tasks) w Panelu Sterowania.

Ikona Work Queue (Kolejka zadań), znajdująca się w konsoli Removable Storage (Przechowywanie plików na nośniku wymiennym) podaje aktualny stan operacji wykonywanych w bibliotece taśm. Jeśli nie można zainicjować operacji, sprawdź w Work Queue (Kolejka zadań), czy zadanie jest wykonywane, czeka lub zakończyło się błędem.

Najczęstszą przyczyną zawieszania się jest brak taśmy w napędzie lub awaria systemu automatyki biblioteki.

Jeśli zaplanowane zadanie Remote Copy ma wystartować, a w tym samym czasie wykonywane jest kopiowanie plików do biblioteki zdalnej w trybie ręcznym, wtedy zadanie takie przechodzi do kolejki i rozpoczyna się zaraz po zakończeniu kopiowania ręcznego. Nie stanowi to żadnego problemu, ponieważ odpowiednie pliki są już przesłane wcześniej.

Naciśnij OK, aby uruchomić zadanie.
Otwórz Panel sterowania i uruchom program Scheduled Tasks (Zaplanowane zadania). Pojawi się lista zadań usług zdalnego przechowywania plików. Zadanie RemoteStorage_Copy jest aktualnie wykonywane. Przykład przedstawiono na rys. 13.20.

--> Brak rysunku.[Author:E]

Rysunek 13.20. Okno Scheduled Tasks (Zaplanowane zadania). Zadanie RemoteStorageJob_F_CopyFiles jest aktualnie wykonywane. Nie jest to zadanie zaplanowane, więc czas następnego uruchomienia jest ustawiony na Never (Nigdy).

Czas wykonywania zadania kopiowania na taśmę jest zależny od prędkości, z jaką dane są zapisywane na taśmie i liczby przesyłanych plików. Po zakończeniu tego zadania pliki przechowywane zdalnie są przedstawiane przez Eksploratora ze znaczkiem zegara. Przykład przedstawiono na rys. 13.21. W wierszu poleceń pliki zdalne można odróżnić po tym, że mają rozmiar wzięty w nawiasy.

--> Brak rysunku[Author:E] .

Rysunek 13.21. Okno Eksploratora pokazuje pliki zdalne zaznaczone poprzez specjalne ikony.

Pamiętaj, że Eksplorator i wiersz poleceń pokazują rzeczywiste rozmiary plików, a nie obszary zajmowane przez nie na dysku. Aby zobaczyć prawdziwe dane o wykorzystaniu dysku, otwórz okno Właściwości (Properties) danego katalogu lub woluminu.
Otwórz plik zaznaczony jako zdalny. Sterownik taśmy szuka pliku. Otwiera się okno Recalling from Remote Storage (Przywoływanie pliku zdalnego) pokazując, że musisz czekać.
Kiedy sterownik taśmy znajdzie dany plik, jest on przesyłany na dysk i zapisany w katalogu pierwotnym. Jeśli plik szczątkowy (stub file) został przeniesiony do nowego katalogu, to plik zdalny będzie zapisany w nowym położeniu. Plik zachowuje prawa własności i listę ACL.

Ponieważ ktoś korzystał z tego pliku, to pozostanie on na dysku przez okres podany dla usług RSS danego woluminu. Wartość domyślna to 180 dni. Jeśli w bibliotece taśm nie ma taśmy zawierającej dany plik, pojawia się konsola z komunikatem przypominającym administratorowi o włożeniu do napędu odpowiedniego nośnika. Nazwa nośnika zawiera nazwę serwera i numer kolejny woluminu.

Rozmieszczanie plików na taśmie

System RSS jest zaprojektowany jako przezroczysty dla użytkownika. Zgodnie z doświadczeniem autora technologia „niewidzialna dla użytkownika” zwykle oznacza, że związane z nią narzędzia administracyjne są niezgrabne, nudne lub całkowicie niewystarczające dla danego przeznaczenia. Zdalne przechowywanie plików niezupełnie mieści się w takiej kategorii. Resource Kit dostarcza dwa narzędzia do pracy ze zbiorami zdalnymi z wiersza poleceń. Są to programy narzędziowe: Remote Storage Directory (Katalog zdalnego przechowywania plików), Rsdir, oraz Remote Storage Diagnostic (Diagnostyka zdalnego przechowywania plików), Rsdiag.

Program Rsdir podaje szczegóły, które nie są prezentowane w normalnym wydruku katalogu. Jego zaletą jest to, że pokazuje dokładny status pliku zdalnego. Tablica 13.4 pokazuje informacje zawarte w pełnej wersji wydruku Rdir.

Tablica 13.4. Składniki pełnej wersji wydruku Rsdir

Status	Atrybuty	Fizyczne	Logiczne
Create Time	Last Access Time	Last Modify Time	Migrate Time
RC	Last Recall Time	HSM ID	TimeBag ID
File ID	File Version ID	Data Stream	CRC Type
Data Stream CRC	DS Size	DS Start	Data Size
Data Start	File size	File Start	Ver Type
Ver Info	Filename

Wykorzystując te informacje można szybko określić, które pliki zostały przeniesione na taśmę, kiedy je przeniesiono i gdzie zostały przeniesione, co pozwala odszukać na taśmie i odzyskiwać odpowiednie pliki.

Towarzyszący programowi Rsdir program narzędziowy Rsdiag, spełnia te same funkcje, co konsola Remote Management (Zarządzanie przechowywaniem zdalnym). Wykorzystując ten program można oglądać, zarządzać, wznawiać i kopiować zadania w kolejce, jak również kopiować bazy danych usług RSS do plików tekstowych w celu przeglądania i wykrywania błędów. Obydwa narzędzia są pomocne w odnajdywaniu taśm z plikami zdalnymi.

Niekontrolowane przywoływanie plików zdalnych

Największym koszmarem związanym z systemem hierarchicznego przechowywania danych (HSM), oprócz utraty taśm, jest użytkownik, który nagle zaczyna przywoływać z taśmy mnóstwo plików, nie mając świadomości, że może zalać nimi dysk docelowy. To może zdarzyć się całkiem przypadkowo. Księgowy może zacząć sprawdzanie ksiąg rachunkowych z ostatniego roku i w ten sposób rozpocząć szaleństwo przywoływania plików lub użytkownik zada przeszukiwanie starego katalogu w poszukiwaniu określonego ciągu znaków.

W systemie ograniczono liczbę plików, które mogą być przywoływane przez jednego użytkownika poprzez ustawienie wartości parametru Ograniczenie przywoływania (Recall Limit). Parametr określa górną granicę liczby plików, które użytkownik może przywołać, z czasem krótszym niż 10 sekund pomiędzy każdym dostępem do pliku. Ograniczenie może być zmieniane przez administratora w następujący sposób:

Procedura 13.13 Ustawianie ograniczenia zapobiegającego niekontrolowanemu przywoływaniu plików zdalnych

Otwórz konsolę Remote Storage (Zdalne przechowywanie plików).
Kliknij prawym klawiszem myszy na ikonie Remote Storage (Zdalne przechowywanie) i z menu wybierz opcję Properties (Właściwości). Otworzy się okno Properties (Właściwości).
Wybierz zakładkę Recall Limit (Ograniczenia przywoływania), rys. 13.22. Wartością domyślną parametru Maximum number of succesive recalls (Maksymalna liczba poprawnych przywołań) jest 60. Można podać wartość lepiej uzasadnioną, np. 20.

--> Brak rysunku.[Author:E]

Rysunek 13.22. Okno Remote Storage Properties (Właściwości zdalnego przechowywania) przedstawiające zawartość zakładki Recall Limit (Ograniczenia przywoływania).

Wybierz opcję Exempt administrators from this limit option (Wyłącz administratorów spod tego ograniczenia), ale ostrzeż administratorów o niebezpieczenstwie przypadkowego przywoływania dużej liczby plików. Ogranicz ryzyko nie logując się jako administrator, a zamiast tego wykorzystując polecenia RunAs.

Jeśli użytkownik stopniowo otwiera pliki, czyta je i dopiero wtedy przechodzi do następnego pliku to wtedy ograniczenie niekontrolowanego przywoływania nie zadziała. Ważne jest, aby użytkownicy wiedzieli, co oznacza ikona z zegarem i zostali ostrzeżeni przed przywoływaniem plików zdalnych bez opamiętania.

--> Brak punktu 5.[Author:E]

Wykonywanie kopii zapasowych plików zdalnych

Mówienie o robieniu kopii zapasowych plików zapisanych przecież na taśmie może wydawać się przesadą. Jednakże z faktu, że usługi zdalnego przechowywania plików wykorzystują ten sam nośnik danych, na którym wykonywana jest kopia zapasowa, nie wynika wcale, że pliki zdalne są tak samo godne zaufania i nadają się do odzyskiwania danych. Taśmy mogą być i bywają zniszczone, nieczytelne, uszkodzone lub brudne. Napęd DLT jest znany z tego, że potrafi wyciągnąć całkowicie taśmę z kasety wewnątrz napędu. Inne typy napędów mają swoje własne rodzaje awarii.

Nawet w przypadku posiadania biblioteki taśm tak pewnej w działaniu jak prawo ciążenia, istnieją inne rodzaje zagrożeń. Złodzieje mogą ukraść taśmy i napęd taśmowy. Mogą wystąpić pożary, powodzie, trzęsienia ziemi i inne klęski żywiołowe. Promienie kosmiczne wysłane z odległej supernowej mogą wysłać kasetę do nieba. Mówiąc krótko, ochrona tych gigabajtów lub terabajtów plików zdalnych poprzez skopiowanie ich na inny zestaw taśm, jest niezwykle ważna.

Jeśli dany napęd taśmy umożliwia klonowanie danych, najlepszym sposobem zapewnienia ciągłości danych jest skopiowanie całej biblioteki na inny zestaw kaset, a następnie przechowanie tego zestawu poza firmą. Jeśli wykorzystywany napęd nie ma takich możliwości, można użyć programu systemowego Windows 2000 pod nazwą Media Copy (Kopia nośnika). Przykład przedstawiono na rys. 13.23.

--> Brak rysunku.[Author:E]

Rysunek 13.23. Okno Remote Storage Properties (Właściwości przechowywania zdalnego) przedstawiające zakładkę Media Copies (Kopie nośnika)

Ten sposób można stosować tylko wtedy, gdy istnieje przynajmniej jeden dodatkowy napęd taśmy podłączony do danego komputera. Jednorazowo można skopiować najwyżej trzy systemy taśm. Pliki są kopiowane jednocześnie na wszystkie zestawy taśm. Liczbę kopii można wpisać w następujący sposób:

Otwórz konsolę Remote Storage (Zdalne przechowywanie plików) okno Properties (Właściwości).
Wybierz zakładkę Media Copies (Kopie nośnika).
Wprowadź liczbę kopii.
W celu zapamiętania wpisanej wartości naciśnij OK.

Usuwanie woluminu z zakresu działania usług zdalnego przechowywania plików

Po pewnym czasie administrator może zadecydować, że nie chce już dalej mieć plików zdalnych w danym woluminie. Jeśli postanowi przywołać wszystkie pliki, to najpierw musi wyłączyć grupę Administratorzy spod działania ograniczenia niekontrolowanego przywoływania plików. Można pozostawić pliki zdalne na taśmie, ale konieczne są przygotowania, by ochraniać bazy danych zdalnego przechowywania plików. Odzyskiwanie plików zdalnych z taśmy bez baz danych zdalnego przechowywania jest trudne. Przy próbie całkowitego usunięcia usługi zdalnego przechowywania za pomocą wywołania CONTROL PANEL|ADD/REMOVE PROGRAMS, system proponuje dwa sposoby:

Przywołaj skopiowane pliki zdalne. Każdy plik zostaje skopiowany z powrotem na dysk. Jeśli wybrano tę opcję, w oknie Removal Option (Opcje Usuwania) pokazany jest rozmiar obszaru wolnego i rozmiar potrzebny do przywołania wszystkich plików. Jeśli nie ma wystarczająco dużego obszaru wolnego, można usunąć istniejące pliki z dysku lub też skopiować pliki zdalne na inny dysk o większej pojemności.

Opcja Pozostaw skopiowane pliki na taśmie zachowuje pliki zdalne, które już są zapisane na taśmie, ale nie przenosi na taśmę żadnych nowych plików. Pliki pozostawione na taśmie nadal mogą być przywołane przez użytkownika w razie potrzeby. Jeśli usuwanie taśm jest częścią procedury odinstalowywania systemu, to wtedy można użyć zezwoleń NTFS by zabronić dostępu użytkownikom.

W obu przypadkach pierwszym krokiem jest otwarcie konsoli Remote Storage Management (Zarządzanie przechowywaniem zdalnym).

Procedura 13.14 Wyłączanie woluminu z zakresu działania usług RSS

Wejdź do drzewa, aby zobaczyć woluminy obsługiwane przez usługi RSS.
Kliknij prawym klawiszem myszy na pozycji woluminu, który chcesz usunąć i z menu wybierz opcję REMOVE (USUŃ). Pojawi się okno Remove Volume management Wizard (Kreator usuwania woluminu)
Naciśnij Next (Dalej). Pojawi się okno Removal Options (Opcje usuwania), patrz rys. 13.24. Obydwie opcje zostały omówione w zamieszczonym powyżej wprowadzeniu do niniejszej procedury. Przykładowo wybierzemy pozostawienie plików na taśmie na wszelki wypadek.

--> Brak rysunku[Author:E] .

Rysunek 13.24. Volume Management Wizard (Kreator zarządzania woluminem) — okno Removal Options (Opcje usuwania).

Wybierz opcję Maintain copied files in remote storage (Utrzymaj skopiowane pliki na taśmie) i naciśnij Next (Dalej). System poprosi o potwierdzenie.
Aby potwierdzić naciśnij Yes (Tak). Pojawi się okno przedstawiające podsumowanie dotychczasowych działań.
Aby zakończyć działanie kreatora i powrócić do okna Remote Storage (Przechowywanie zdalne), naciśnij przycisk Finish (Zakończ). Ten wolumin nie jest już obsługiwany.

Jeśli użytkownik będzie potrzebował dostępu do pliku zdalnego, co zdarza się następnego dnia, choć plik nie był używany od czasów afery Watergate, można włożyć kasetę do napędu i zezwolić użytkownikowi na korzystanie z pliku zdalnego. Jak długo baza danych zdalnego dostępu (Remote Access database) pozostanie nietknięta, tak długo pliki zdalne będą dostępne.

Odzyskiwanie bazy danych przechowywania zdalnego

À propos afery Watergate, nie istnieje coś takiego jak niezniszczalne taśmy czy niezniszczalne katalogi taśm. Trwałość taśmy zależy od sposobu postępowania z kasetą i napędem. Z drugiej strony, trwałość katalogu jest w większym stopniu poza zasięgiem administratora.

Bazy danych Windows NT (Jet databases) nie były przykładem pewności działania. Może nowa technologia baz danych Windows 2000 jest lepsza, a może nie. Jedno jest pewne — przy odpowiednio długim stosowaniu RSS w odpowiednich systemach administrator znajdzie się w sytuacji, w której zajdzie potrzeba odzyskiwania plików z powodu utraconej lub obarczonej błędami bazy danych RSS.

Na przykład użytkownik zgłasza, że plik z zegarem na ikonie jest niedostępny, a administrator także nie może go otworzyć, chociaż taśma jest w napędzie lub nastąpiła awaria serwera i administrator jest zmuszony ponownie instalować Windows 2000.

Ta awaria dotknęła katalogu taśm zdalnego przechowywania plików i woluminu zawierającego pliki szczątkowe (stub files). Aby baza danych działała poprawnie, pliki resztkowe muszą znaleźć się w pierwotnym położeniu, a pliki systemowe Windows 2000 muszą znaleźć się na tym samym dysku i w tym samym katalogu. W przypadku awarii systemu administrator musi zrobić, co następuje:

Ponownie zainstalować Windows 2000

Odtworzyć pliki źródłowe z kopii zapasowej

Odtworzyć bazy danych RSS ze zdalnej biblioteki taśm.

Bazy danych RSS są zapisane w katalogu \WINNT\System32\RemoteStorage. Odbudowa bazy danych RSS związana jest z odbudową bazy danych przechowywania na nośniku wymiennym (Removable storage database — RSM), znajdującej się w katalogu \WINNT\System32\NTMSDATA. Usługi RSS potrzebują bazy danych RSM do znajdywania nośnika w puli nośników (media pools).

Bazy danych RSS i RSM są kopiowane na taśmę RSS automatycznie, po to, by umożliwić odzyskiwanie danych po awarii systemu. Ogólne sposoby odzyskiwania baz danych po całkowitym zniszczeniu systemu operacyjnego są następujące:

Procedura 13.15 Postępowanie przy odbudowie danych po utracie RSS

Zainstaluj ponownie Windows 2000 bez usług zdalnego przechowywania plików (Remote Storage Services). Najpierw musisz odtworzyć bazy danych.
W wypadku uszkodzenia dysku zawierającego pliki szczątkowe (stub files), odtwórz je z taśmy --> . Drive letter [Author:PGon] i nazwa woluminu muszą być identyczne. Dobrym zwyczajem jest zapisanie tego w bibliotece RSS, aby była dostępna w razie potrzeby.
Sprawdź zawartość taśmy RSS używając konsoli Removable Storage Mangement (Zarządzanie przechowywaniem danych na nośnikach wymiennych).
Odtwórz bazy danych RSS i RSM do pierwotnego położenia.
Przenieś bazę danych RsEng do katalogu tymczasowego.
Zainstaluj ponownie Usługi zdalnego przechowywania plików (Remote Storage Services).
Odtwórz moduł programowy Engine database z kopii zapasowej bazy danych na taśmie.
Sprawdź, czy pliki zdalne są dostępne.

Wykonaj kolejne etapy tej procedury odtwarzając bazy danych i odzyskując dostęp do plików. Jeśli system operacyjny nadal działa, ale bazy danych zawierają błędy, ich odbudowę przeprowadza się w następujący sposób:

Procedura 13.16 Odzyskiwanie RSM i RSS z taśmy

Zainstaluj ponownie Windows 2000 i pliki źródłowe RSS w pierwotnym położeniu.
Włóż Taśmę RSS do napędu lub zainicjuj bibliotekę taśmową wkładając pierwszą taśmę do napędu.
Otwórz konsolę Computer Management (Zarządzanie komputerem) i przejdź do pozycji Removable Storage (Przechowywanie danych na nośnikach wymiennych).
Znajdź nośniki RSS pod Imported (Importowane). Nazwa nośnika zaczyna się od liter RS, po nich następują: nazwa serwera i numer kolejny, np. RS-PHX-DC-01-001.
Przenieś nośnik do puli nośników usługi Backup (Backup pool). Jeśli pula nośników usługi Backup (Backup pool) jest niedostępna, uruchom program tworzenia kopii zapasowych START|PROGRAMS|ACCESORIES| SYSTEM TOOLS|BACKUP, który zainicjuje pulę nośników (Backup pool).
Mając nośnik w polu Backup uruchom program tworzenia kopii zapasowych START|PROGRAMS|ACCESORIES| SYSTEM TOOLS|BACKUP.
Wybierz zakładkę Restore (Odtwórz).
Rozwiń drzewo, aby zobaczyć nośniki RS.
Zaznacz nośniki RS. Z menu wybierz TOOLS|MEDIA TOOLS \ CATALOG. System przeszuka taśmę i stworzy katalog. Operacja ta może trwać bardzo długo. Jeśli pliki zajmują kilka gigabajtów, bądź przygotowany na kilkunastogodzinne oczekiwanie na uzyskanie katalogu.
Po zakończeniu katalogowania ikona przedstawiająca pierwotny dysk i wolumin pojawia się pod ikoną Media (Nośniki).
Kliknij na znaku plus przy nośnikach, aby pokazać podkatalogi.
Wybierz katalogi \WINNT\System32\Ntmsdata i \WINNT\System32\RemoteStorage. Jeśli pojawi się kilka wersji tych katalogów, wybierz najnowsze. Określenia daty wymaga załadowania katalogów. Otwieranie katalogu może trwać bardzo długo.
W dolnej lewej części okna znajduje się opcja Restore Files To (Odtwórz pliki do), która powinna być ustawiona na Original Location (Położenie pierwotne). W innym przypadku system odtworzy pliki do zastępczego położenia o nazwie RSS Managed Volume (Wolumin zarządzany przez usługi RSS). Jeśli przypadkowo odtworzysz pliki w złe położenie, można je skopiować ręcznie do prawidłowego miejsca.Naciśnij Start Restore (Odtwarzanie). Pojawi się okno Advanced Options (Zaawansowane). Naciśnij Advanced (Zaawansowane).
Wybierz Restore Removable Storage Database (Odtwórz bazę danych przechowywania na nośnikach wymiennych). Usługi RSS korzystają z tej bazy danych do znajdywania pierwotnych nośników w puli nośników (media pools), zapamiętanych w tej bazie.
Aby rozpocząć odtwarzanie naciśnij OK. Po zakończeniu tej operacji, zamknij okno odtwarzania i zakończ program Backup.
Otwórz konsolę Computer Management (Zarządzanie Komputerem) i przejdź do gałęzi drzewa Removable Storage Management (Przechowywanie na nośnikach wymiennych).
Sprawdź, czy pula nośników (media pools) została odtworzona.

Teraz nadszedł czas, aby zainstalować usługi zdalnego przechowywania plików (Remote Storage Services), wykorzystując CONTROL PANEL|ADD/REMOVE SOFTWARE|INSTALL WINDOWS COMPONENTS. Po zakończeniu kopiowania plików należy ponownie uruchomić komputer i postępować dalej zgodnie z następującą procedurą:

Procedura 13.17 Odzyskiwanie bazy danych RSS

Otwórz COMPUTER MANAGEMENT (Zarządzanie komputerem)|SERVICES (Usługi).
Zatrzymaj następujące usługi: Remote Storage Engine, Remote Storage Media i Remote Storage File.
Otwórz Eksploratora i przejdź do folderu \WINNT\System32\RemoteStorage\EngDB.
Przenieś zawartość folderu \EngDB do folderu tymczasowego np. C:\Temp\EngDB. (Uwaga: Baza danych EngDB będzie odzyskiwana z kopii zapasowej w dalszej części niniejszej procedury).
Otwórz wiersz poleceń.
Przejdź do katalogu \WINNT\System32\RemoteStorage\EngDB.
Wprowadź polecenie w postaci: rstore \WINNT\System32\RemoteStorage\EngDB.bak. Jeśli odtwarzanie zakończy się pomyślnie, system wyświetli komunikat Restore Succeded (Odtwarzanie zakończone prawidłowo).
Powróć do konsoli Computer Management (Zarządzanie komputerem).
Uruchom ponownie następujące usługi: Remote Storage Engine, Remote Storage Media i Remote Storage File.
Sprawdź odtworzenie otwierając napęd zawierający pliki szczątkowe (stub files) i przywołując jeden lub dwa z nich.

Usługi zdalnego przechowywania plików (RSS) — podsumowanie

Oto najważniejsze informacje dotyczące usług zdalnego przechowywania plików:

RSS jest zestawem usług przeznaczonych do kopiowania plików z dysku na taśmę i utrzymywania ich dostępności dla systemu plików.

RSS wymaga lokalnego napędu taśmy.

RSS obsługuje tylko woluminy NTFS5, ponieważ do śledzenia położenia pliku wykorzystuje wskaźniki lokalizacji pliku (Reparse Points).

Pliki zawierające wskaźniki lokalizacji są zapisane w bazie danych $Reparse. Dziennik zmian (Change Log) chroni bazę danych w celu szybkiego odzyskania po awarii systemu.

Pliki z katalogów dołączanych nie są przenoszone na taśmę.

Dla usług RSS powinien być przeznaczony oddzielny serwer, co zmniejszy komplikacje w wypadku odzyskiwania systemu zdalnego przechowywania plików.

Poruszając się do przodu

Na tym etapie system Windows 2000 jest prawie gotowy do przyjmowania danych od użytkowników. Tematem następnego rozdziału jest zapewnienie przechowywania danych tam, gdzie dostęp mają tylko użytkownicy do tego upoważnieni.

Koniec.

Strona: 1
Do tłumacza: co to za gra? W Polsce nie ma takiej gry...

U.Płonka — OK, jest taka gra. Można dać przyp. red.

Myślę, że ma być 65 536.

65 536?

Dalej jest eksabajtów, trzeba ujednolicić, ale nie ma w słowniku.

eksa-, czy exa- ?

Lepiej unikatowym, ale nie wiem, czy nie funkcjonuje to jako część nazwy.

Brak polskich odpowiedników.

Strona: 2
Brak rysunku

Brak pogrubienia.

Strona: 1
Sprawdzić rozszerzenia, czy to nie NLM?

Wyróżnienie kursywą nie jest potrzebne.

Nie ma pogrubienia.

Brak pogrubienia i kursywy.

Brak pogrubienia.

Strona: 1
Sprawdzić w oryginale!!!!

Proszę poprawić na podstawie oryginału, mam wrażenie, że brakuje tekstu.

niewłaściwe słowo

Strona: 2
Brak rysunku!!!

Brak pogrubienia.

Głównym?

Strona: 2
Brak rysunku!

Chyba długie!

To chyba jest jakaś bzdura!

Strona: 1
Sprawdzić w oryginale

Brak pogrubień.

Zmniejszyć spacje.

Strona: 45
??? ( sens tego zdania)

Strona: 46
Brak rysunku!!!

Strona: 47
A to jest opis do rysunku, którego nie ma :=))

Sprawdzić, czy to ten paragraf

Strona: 52
Propozycja: K:\Moje Dokumenty

??? Sprawdzić w oryginale

Proszę sprawdzić w oryginale, czy ma być 100 000, czy 1 000 000?

Do tego miejsca poprawione.Kolejne strony postaram się jak najszybciej...

Proszę sprawdzić z oryginałem, co tu wpisać.

Sprawdzć tłumaczenie

Nic takiego nie wywnioskowałam z przeczytanych wcześniej akapitów - proszę sprawdzić w oryginale.

Brak pogrubień.

Brak rysunku.

Strona: 72
Brak rysunku!!!

Strona: 73
Brakuje tekstu ze strony 895:

Wskazówek dotyczących Ograniczeń i zarządzenia plikami, oraz podsumowania tematu.

Sprawdzić nazwę przetłumaczoną

Strona: 76
Brak rysunku!!!

Strona: 77
Brak rysunku!!!

Strona: 78
Brak rysunku!!!

Strona: 79
Brak rysunku!!!

Strona: 80
Brak rysunku!!!

Strona: 80
Brak punktu 5!!!( str 79)

Brak rysunku!!!Strona: 81

Strona: 82
Brak rysunku!!!

Czemu to nie jest przetłumaczone?

Wyszukiwarka

Podobne podstrony:
r18-07, ## Documents ##, Windows 2000 Server. Vad. prof
r09.07, ## Documents ##, Windows 2000 Server. Vad. prof
r15-07, ## Documents ##, Windows 2000 Server. Vad. prof
r03-06, ## Documents ##, Windows 2000 Server. Vad. prof
r06-06, ## Documents ##, Windows 2000 Server. Vad. prof
r04-06, ## Documents ##, Windows 2000 Server. Vad. prof
07 MS Windows 2000 Server Rozdział 5

więcej podobnych podstron