Re: Outlook Express 7 pod Vistą

Użytkownik "Sławomir Stępniak" <slaw1step@poczta1.1onet.pl> napisał w
wiadomości news:ffbl4j$fom$1@news.onet.pl...
>> FAT32 nie ma problemów z ilością plików (narzut jest MNIEJSZY niż w
>> ntfs).
>
> per directory to ma - 2^16-2 a NTFS - unlimited

Wejdzie więcej w FAT(32), ino problem będzie z dostaniem się do pliku
(1), polegną też wszelkie (ja sprawdziłęm 3, czy 4, nie pamiętam)
programy typu scandisk.

> wygląda kosmicznie dużo, ale np. control.cancel pokazuje mi teraz
> 109706
> (fakt większość niepobranych, ale jakbym czasem się uparł :)
> zarżnąłbym
> FATa (FATę?) na śmierć)

Weszło by prawdopodobnie, ale - zastrzeżenie (1)

>> Co do klastrów - na typowej "dzisiejszej" partycji rzędu dziesiątek
>> gigabajtów FAT32 ma klastry 16-kB, a NTFS 4-kB, więc różnica jest.
>
> No i dodatkowo w NTFS co pomniejsze posty mogą się dać upchać
> bezpośrednio w MFT, wtedy już w ogóle problemu nadmiarowości nie ma.

Fajnie to wygląda, przy okazji jakiejś rozwałki (prawie w całości
odzyskanej) filesystemu pooglądałem sobie także wpisy NTFS - niektóre
puste, a tu np. pliki typu boor.ini za wpisem do katalogu treść pliku,
nawet kompresować nie było po co.

(1) Kiedyś, jeszcze w DOSie, postanowiłem się "zabawić", ile mi wejdzie.
Zrobiłem tworzenie n plików o długości zero, aby nie wpisywało do FAT, a
tylko w katalog. Już gdzieś od tysiąca plików czas dostępu do ostatnich
wydłużył sie wyraźnie... dopchnąłem gdzieś do ok. 33 tysięcy, bez
buforowania dysku dostęp do ostatnich trwał nawet po kilka/naście minut.
NAWET z buforowaniem (smartdrv z dużym buforem) - ponad pół minuty. Cóż,
jedziemy, skasowałem wszystko, co widać było w katalogu - dupa, jeden
plik nie poszedł... bo jeden tylko widać było. Ciach, delete, znowu jest
plik... ale o innej nazwie... Okazało sie, że powyżej 32767 plików widać
tylko pierwszy dostępny, obojętnie, w jaki normalny sposób do tego
podejść. A czas dostępu nawet z buforowaniej jest tragiczny. Wyszło na
to, że to z powodu młócenia dyskiem (fragmentacja!) i milisekundowe
czasy ponakładały się na wielosekundowe. Pomyślałem - defrag. Już na
starcie out of memory. Scandisk, norton disk doctor (dwie wersje),
chkdsk (DOSowy), poległy - nie zmieściły im się dane.
Aby zafundować sobie podobne kłopoty (a i tak w rezultacie mniejszego
kalibru) w NTFS, to w NT4 utworzyłem ponad 2.5 miliona katalogów, równo
rozkładając je pośród gałęzi drzew (nie waliłem wszystkich w jeden
katalog nadrzędny). Bez problemu dalo sie to skasować. Jedynym minusem
okazało sie, że coś przy tym kasowaniu zgrzytnęło i PM odmówił konwersji
na FAT. CHKDSK po długim mieleniu zeznawał, że filesystem jest zdrowy.
Diskeeper nie pamiętam, czy nic wielkiego nie widział i uznawał, ze jest
zdefragmentowane, czy odmawiał tejże... SpeedDisk ponad godzinę usiłował
się poskładać z danymi, ale rezygnowałem, nie doczekawszy... Bo system
zarzynał. Sprawdzę to jeszcze obecnie - wtedy była znacznie słabsza
maszyna, mniej pamięci, wolniejszy dysk... Sposobem na błąd
uniemożliwiający konwersję było ponowne utworzeie tych 2.5 miliona
katalogów i trochę więcej, aby zastąpić leżący gdzies uszkodzony wpis
MFT, nowym. Po tym konwersja zatrybiła bezproblemowo.
Minusem tu było to, że miejsce na dysku, po usunięciu wpisu w MFT,
zwalniane nie było i po moich próbach ok. 2.5-2.7 GB poszło się...
wiecie co. Ale za to przy tworzeniu nowych plików nie było zajmowane
nowe miejsce na wpisy MFT (ale nie na same pliki), lecz brane z juz
istniejących. Wydaje mi się jednak, że ten minus, to nie minus samego
systemu plików, tylko konkretnej jego realizacji, w FAT problem ten
rozwiązywał się przy defragmentacji, tu nie miałem możliwości tego
sprawdzić.
Ważną różnicą jest to, że znacznie bardziej obciążony strukturą systemu
plików NTFS po takich działaniach, Windows NT4 radził sobie z tym
znacznie płynniej, niż z FAT, samo korzystanie było niemalże
bezproblemowe, żadnych więklszych przytlumień, mimo braku UDMA.

-- 
LH
"Ten, kto nie ceni i nie szanuje przeszłości,
 niegodzien jest szacunku ani prawa do przyszłości"
(C) Józef Piłsudski, Marszałek Polski.