Z jakiego algorytmu alokacji bloków korzysta NTFS?

Na Windows XP 64 pobrałem plik o pojemności 1,2 GB, który, jak pokazuje obrazek, został sfragmentowany. Niestety, przed zrobieniem migawki z Piriform Defraggler zdefragmentowałem pozostałe pliki, więc nie możesz zobaczyć dokładnego stanu w miejscu, w którym plik został zapisany. Jednak dysk był cały czas tak pusty jak teraz (zużyto 25%) i prawie nie był pofragmentowany.

Z jakiego algorytmu alokacji bloków korzysta NTFS? Wygląda to losowo, a może umieszczenie go w miejscu, w którym faktycznie stoi głowica dysku.

AKTUALIZACJA:

Tak stało się dzisiaj po napisaniu 67 MiB nowego pliku. Został podzielony na 731 fragmentów, średnia wielkość to tylko 95 KiB. Plik został wykorzystany do wypełnienia niektórych luk, ale nie wszystkich, nie wykorzystuje też ogromnej ciągłej wolnej przestrzeni. Dziwne, prawda?

AKTUALIZACJA 2:

W przeciwieństwie do PC Guru , naprawdę nie sądzę, że Opera jest winowajcą. Myślę, że to (w przeciwieństwie do Google Chrome) nie mówi Windowsowi o oczekiwanym rozmiarze, jednak w wielu przypadkach nie jest to możliwe i na OS spoczywa odpowiedzialność za rozsądną obsługę. Poniższy obrazek pokazuje, co się stało po kilku dniach, kiedy prawie nic nie robiłem na tej partycji - katalog TEMP i wszystkie moje dane (z wyjątkiem tych zarządzanych przez Windows) znajdują się gdzie indziej. Sam system Windows wydaje się nie używać SetEndOfFilei fragmentuje własne pliki w okropny sposób (600 fragmentów na kilka małych plików o wielkości około 40 MB). Wygląda na to, że NTFS nie używa pierwszego dostępnego sektora, ponieważ znów znajdują się pliki na środku, a także pod koniec całkiem pustego dysku (zużycie 23%),

IIRC, system plików NTFS próbuje przydzielić plik w ciągłej pamięci. Może to jednak zrobić tylko wtedy, gdy system plików zna rozmiar pliku. Jeśli otworzysz plik i zaczniesz do niego pisać, zapisze on „najlepsze” miejsce, w którym zmieści się plik (zwykle w kierunku zewnętrznej części talerza). Ale to „najlepsze” miejsce może nie być wystarczająco duże, aby zmieściło się w pliku.

Jeśli aplikacja poinformuje NTFS o rzeczywistym rozmiarze pliku (za pomocą SetEndOfFile ()), NTFS może lepiej znaleźć ciągłe miejsce na plik (SetEndOfFile API powoduje, że NTFS przydziela miejsce dla całego pliku).

Twój problem musi dotyczyć Opery. Właśnie obejrzałem kilka plików na bardzo pełnym i pofragmentowanym dysku. Duże pliki pobrane za pomocą Chrome były ciągłe.

Sugeruje to, że Chrome znał rozmiar pliku na początku pobierania, więc powiedział NTFS, jakiego rozmiaru pliku się spodziewać. Jeśli to zrobisz, NTFS spróbuje umieścić plik w jednym fragmencie lub, gdy żaden fragment nie jest wystarczająco duży, w największych dostępnych fragmentach. Co ciekawe, zawsze używa tych fragmentów w malejącej kolejności wielkości, więc duże pliki skopiowane przez Eksploratora na pofragmentowany dysk mogą przeskakiwać po całym dysku.

Jeśli program nie zna rozmiaru pliku lub nie zawraca sobie głowy informowaniem NTFS, ale zamiast tego po prostu otwiera plik i zaczyna zapisywać dane sekwencyjne, wydaje się, że NTFS działa bardzo podobnie do FAT32, który po prostu zaczyna się od pierwszego dostępnego klastra (lub pierwszy dostępny po ostatnim przydzielonym w tej sesji) następnie wykorzystuje wszystko, co jest dostępne od tego momentu. Jako przykład, w tym samym czasie poprosiłem CCleaner o zeskanowanie rejestru, co spowodowało utworzenie kopii zapasowej dużego pliku txt „.Reg”. Ten plik zaczął się w pobliżu początku dysku, a następnie został rozrzucony na 127 różnych fragmentach. W przeciwieństwie do plików skopiowanych za pomocą Eksploratora lub pobranych za pomocą Chrome, w każdym pliku, który przeglądałem, klastry były przydzielane w kolejności rosnącej.

Do tych badań wykorzystałem Winhex (bezpłatna wersja próbna dostępna na Winhex.com). Patrząc na wpis w katalogu. kliknij nazwę pliku prawym przyciskiem myszy i wybierz Pozycja, Lista klastrów, aby wyświetlić listę klastrów używanych przez ten plik.