Autor: Jarek Lis (lis_at_ict.pwr.wroc.pl)
Data: Thu 31 Oct 1996 - 11:38:57 MET
Krzysztof Halasa <khc_at_hq.pm.waw.pl> wrote:
: FAT nie nadawal sie nawet do dyskow 40MB :( Byl efektywny, dopoki
: miescil sie w calosci w pamieci RAM, czyli dopoki zajmowal max.
: kilka sektorow, jak na dyskietce 1.2MB.
: Troche pomoglo zastosowanie disk cache (wtedy oczywiscie FAT byl
: caly czas czytany do RAM, ale z owego cache - czyli rowniez z RAM).
A tam. Buffers=5, i system dziala dwa razy szybciej niz przy 3.
A dajesz 20, i starczy, jesli to nie sa bazy danych.
Na dzis, to bym sie zdecydowal na cluster jakies 4KB (mniejszej porcji
z dysku nie warto czytac :-( ], wiec FAT16 do jakis 250MB by sie nadawal..
: > System plikow zastosowany o os/2 jest zdaje sie jeszcze lepszy niz unix
: > bo starcza jedna pozycja katalogu dla jednego pliku. W unixie dla duzych
: > pl;ików moga byc potrzebne dodatkowe węzly nawet jeśli plik jest ciągłym
: > obszarem na dysku.
: Nawet jesli tak jest w przypadku konkretnego filesystemu Unix'a, to
: i tak nie ma to zadnego znaczenia - utrata jednej pozycji katalogu dla
: kilkuMB pliku jest calkowicie bez znaczenia. Istotne sa takie cechy
: filesystemu, jak sprawnosc operacji na plikach, trudnosc zniszczenia
: wiekszej ilosci plikow itp.
To mowiac szczerze U*x fs sa tu takie sobie...
: Oczywiscie istotne jest takze, by pomocnicze
: dane o plikach (wszelkie FATy, tablice inodow, itd w zaleznosci od
: filesystemu) zajmowaly jak najmniej miejsca w stosunku do wlasciwych
: danych, ale to zwykle nie jest problemem.
Smiem twierdzic ze one zajmuja mniej wiecej tyle samo, niezaleznie od fs.
Jarek.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:35:53 MET DST