Re: czynniki sprzyjające fragmentacji

Autor: Araneus Diadematus <warchlak_at_chlewik.pl>
Data: Tue 01 Jun 2010 - 15:08:53 MET DST
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=response
Message-ID: <4c050666$1@news.home.net.pl>

Użytkownik "Adam" <a.g@poczta.onet.pl> napisał w wiadomości
news:hu2dtp$8oj$1@news.onet.pl...
> Teoretycznie np. NTFS miał być odporny na fragmentację. Czyli jeśli
> system operacyjny "widzi", jaki ma duży plik do zapisania, i zapisuje
> go nie w pierwszym wolnym miejscu, tylko wrzuca gdzieś w większą wolną
> przestrzeń - wtedy fragmentacja jest znikoma, o ile nie zapełnimy
> prawie całego dysku. Windowsy do XP włącznie "udawały", że tak robią.
> Linuxy tak robią.

Już Windows 98, jeśli wiedział, jak duży będzie plik, wyszukiwał
pierwszy ciągły wolny obszar i wrzucał tam plik. Nie potrzeba do tego
NTFS-a. Zdaje mi się, że miał nawet wartość ustawianą w rejestrze, ile
musi mieć dany ciągły wolny obszar, by był wzięty pod uwagę przy
zapisywaniu pliku.

> Zresztą chyba Vista i Win7 nie umieją rozrzucać plików (na systemie
> NTFS), tyklo robią "cichą" defragmentację. Nie wiem, jak wygląda
> sprawa Win7 na WinFS (jeśli już WinFS jest).

WinFS wg Wiki (tak, wiem...) to ponoć miała być nakłądka na NTFS, gdzie
miały zniknąć pojęcia plików, katalogów... Sory, nie chce mi się teraz
sięgać do artykułów po szczegóły...

> Stąd też wynika wniosek, że jednak chyba bardziej zależy to od
> konkretnego OS-a. Jednak nie testowałem tego osobiście z linuxem
> postawionym na FAT -

Otóż właśnie. Nie widzę najmniejszych przeszkód, by OS mający pod sobą
FAT, wykorzystywał ten FAT w sposób redukujący fragmentację, z cichym
defragiem włącznie.
Zresztą, FAT64, gdzie w istocie wpis w FAT nadal jest 32-bitowy (macałem
już FAT w tym filesystemie), może obsługiwać prawa dostępu, czyli ACL,
ADS, inne, to w filesystemie sprawa wtórna. Skoro w FAT pod Linuxem dało
się zrobić prawa dostępu, ciut naokoło, ale się dało...?

> może kiedyś sprawdzę.

Daj znać, jakie rezultaty.

-- 
((*))
((+))
Received on Tue Jun 1 15:10:02 2010

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Tue 01 Jun 2010 - 15:42:01 MET DST