Dlaczego defragmentacja dysku C zwiększyła moje wolne miejsce na dysku o 10 GB?

Użyłem Defragglera do defragmentacji wolnego miejsca na moim 100 GB dysku C: \, który był pełny 85 GB. Po defragmentacji dysk pokazał pełne 75 GB. Jak magicznie pojawiło się 10 GB wolnego miejsca? Czy straciłem jakieś dane?

Zrobiłem czyszczenie dysku przed defragmentacją, a mój kosz miał tylko około 11 MB, więc nie może to być spowodowane czyszczeniem plików tymczasowych. Zauważ, że zdefragmentowałem „wolne miejsce”, co oznacza, że ​​powinien był zmienić układ pustych bloków tak, by były ciągłe.

Prawdopodobnie stało się tak, że operacja defragmentacji zmusiła system Windows do wyrzucenia niektórych migawek przywracania systemu. Patologicznym przypadkiem fragmentacji byłoby spowodowanie, że narzut metadanych stanowiłby pełne 10% miejsca na dysku w stosunku do tego, co normalnie używa Windows. nawet wtedy nie jestem pewien, czy to możliwe.

W historii lub dokumentacji Defragglera nie widzę niczego, co wskazywałoby, że jest w stanie poprawnie defragmentować pliki, aby zapobiec czyszczeniu kopii w tle. W rzeczywistości ten wątek z forum pomocy Defragglera wskazuje, że wie, że to się dzieje (w wątku jest post od administratora forum zatytułowany „Official Piriform Bug Fixer”), ale nie wskazuje, czy zamierzają to naprawić.

Kopie w tle mogą zostać utracone podczas defragmentacji woluminu : Dzieje się tak dlatego, że domyślnie VSS działa z klastrami 16 KB, podczas gdy większość woluminów NTFS jest formatowana z klastrami 4 KB. Więc jeśli operacja defragmentacji przenosi dane, które nie są wielokrotnością klastra 16 KB (lub „odległość”, którą przeniesiono, nie jest wielokrotnością 16 KB), wówczas VSS będzie śledzić je jako zmianę i może wyczyścić wszystkie twoje migawki.

MSDN: Defragmentacja plików :

Jeśli to możliwe, przenieś dane w blokach wyrównanych względem siebie w przyrostach co 16 kilobajtów (KB). Zmniejsza to obciążenie związane z kopiowaniem przy zapisie, gdy kopie w tle są włączone, ponieważ przestrzeń kopiowania w tle jest zwiększana, a wydajność zmniejszana, gdy występują następujące warunki:

• Rozmiar bloku żądania przeniesienia jest mniejszy lub równy 16 KB.
• Delta przesunięcia nie jest zwiększana co 16 KB.

Wbudowana defragmentacja Vista nie robi tego :

Jedną ze zmian, która nie jest oczywista dla użytkowników, jest nasza optymalizacja kopiowania w tle podczas defragmentacji. Defrag ma specjalną heurystykę, aby przenosić bloki plików w sposób, który zminimalizuje aktywność kopiowania przy zapisie i zużycie obszaru przechowywania kopii w tle. Bez tej optymalizacji proces defragmentacji przyspieszyłby usuwanie starszych kopii w tle.

Każdy fragment musi być gdzieś śledzony. Wymaga to przestrzeni dyskowej (w ramach hydrauliki systemu plików, a nie rzeczy, do których masz bezpośredni dostęp).

Przykład: Załóżmy, że masz jeden plik z 1000 fragmentami. W ten sposób plik jest przechowywany przez zbiór losowych bloków. Zamiast pojedynczego ciągłego bloku. Oznacza to, że pofragmentowany plik wymaga 1000 razy więcej miejsca do przechowywania w instalacjach systemu plików, choćby do przechowywania adresów dla każdego fragmentu. Instalacja systemu plików utrzymuje małe słowniki / bazy danych / mapy / tabele / listę w lokalizacji każdego fragmentu pliku. Tak więc, dla hydrauliki systemu plików, przechowywanie listy wskaźnika pojedynczego fragmentu nie wymaga dużo miejsca, w porównaniu do listy 1000 wskaźników fragmentów.

Ale hej, może się mylę ...

Edycja: informacje pomocnicze stąd :

Gdy strumień danych nierezydenta jest zbyt rozdrobniony, tak że jego skuteczna mapa alokacji nie może całkowicie zmieścić się w rekordzie MFT, mapa alokacji może być również przechowywana jako strumień nierezydenta, z niewielkim strumieniem rezydentnym zawierającym alokację pośrednią odwzorować na skuteczną mapę alokacji nierezydenta strumienia danych nierezydenta.

Tłumaczenie: Jeśli masz duże rozdrobnienie, ogólne założenia dotyczące hydrauliki systemu plików nie będą miały zastosowania. W związku z tym FS musi podjąć kroki w celu dostosowania się do fragmentacji i ostatecznie kosztuje dodatkowe miejsce do przechowywania, po prostu w celu zarządzania fragmentami. Dokładnie zgaduję od samego początku.

Edycja: Biorąc pod uwagę powyższe, nadal wydaje się, że 10 GB jest tracone tylko z powodu fragmentacji plików jest szalone. Założę się, że podczas defragmentacji wystąpiło typowe uszkodzenie systemu plików, które zostało automatycznie poprawione. Myślę, że nie tylko miałeś duże rozdrobnienie, ale także częściowo usunięte pliki zajmujące miejsce. Byłoby miło zobaczyć dziennik scandisk z tej defragmentacji (lub serii scandisk przed defragmentacją)