Użytkownik <radekp@konto.pl> napisał w wiadomości
auh84ch64ie63r11e90ds7k32shrlq8itb@4ax.com">news:auh84ch64ie63r11e90ds7k32shrlq8itb@4ax.com...
Sun, 4 Dec 2016 16:28:31 +0100, w <o21cmq$fk9$1@node2.news.atman.pl>,
"HF5BS"
<hf5bs@t.pl> napisał(-a):
Gdy plik jednak będzie porozrzucany, dojdzie do tego 1000x50ms=50s (do
tego
jeszcze 1 ms na odczyt) i do naszych 8 sekund dojdzie kolejne 50, więc
odczyt takiego pliku potrwa prawie minutę. Co lepsze, 8 sekund, czy 58
Że pliki mogą być pofragmentowane, to ja wiem. Ale żeby aż tak? Sądziłem,
że
Windows potrafi o to bardziej zadbać.
No, aż tak. ok. tysiąca plików znaczących, w ponad 2 milionach fragmentów.
Oczywiście, proporcje czasów dostępu nieco inne, ale różnice mniej-więcej na
tym polegają, co podałem w przerysowanym przykładzie.
A sytuacja taka, że nie ma siły na nie-fragmentację - wielkość pliku
wynikowego jest nieoznaczona i musi dopisywać po kawałku, za nim inny
kawałek, później znów gdzieś dziura i trzeci, itd, itp, po caluśkim
woluminie. Żaden algorytm tego sensownie nie przeskoczy (nawet IMHO linowy
sposób na ext-ileś), albo komp zmuli na amen, gdyby jakiś próbował. Może
gdybym codziennie defragmentował... ale to z kolei chyba nie było by zbyt
mądre? Chociaż w takiej sytuacji, to kto wie?
Muszę więc czekać, aż znowu zacznie przymulać, wtedy strata czasu na
zrobienie porządku będzie względnie najmniejsza. W trakcie ostatniego
"sprzątania" ustaliłem sobie parę "procedur" i następne takie porządki
powinny już pójść szybciej.
Wbudowane w NTFS "extenty" też nie poradziły. Nawet nie próbuję sobie teraz
wyobrazić, jak by to się działo na FAT32, choć może z ciekawości kiedyś
spróbuję też tak poszatkować dane?
--
...Ja biorę na siebie schody, znajdę je skubane i skopię im poręcz
tak, że nie będą wiedziały, którędy na górę. (C) Osioł ze Shreka.
|