Autor: Radosław Sokół (rsokol_at_iname.com)
Data: Tue 09 Sep 1997 - 13:39:48 MET DST
Odpowiadając na dwa poprzednie listy:
- wielkość jednostki alokacji musi mieć wpływ na wydajność
systemu. Po prostu zwiększa się ich liczba - więc
wszystkie obliczenia spowalniają. Jeśli jeszcze
wychodzimy poza granicę 16 bitów na indeks jednostki,
dodatkowo spowalniamy program, bo instrukcje operujące
na 32 bitach nigdy nie będą szybsze od szesnastobitowych,
a same numery clusterów muszą zajmować dwa razy więcej
miejsca.
- mniejsza jednostka alokacji sprzyja fragmentacji.
Co prawda można jej zapobiegać (jak np. w OS/2), ale
dla przykładu zapobieganie fragmentacji w NT jest
dość dyskusyjne.
Niewątpliwie większa jednostka alokacji powoduje straty na
pojemności i przy dużej ilości małych plików jest to istotne.
Dlatego zgadzam się z przykładem serwera news. Ale nie
opłaca się dążyć do najmniejszej jednostki alokacji za
wszelką cenę. Prościej jest tak zmodyfikować programy,
aby używały mniejszej ilości dużych plików niż większej
małych, niż komplikować tak FS aby był szybki i oszczędny
zarazem - co nie udało się ani w NTFS, ani w HPFS, a tym
bardziej w VFAT32. Co nie zmienia faktu, że wszystkie trzy są
lepsze, niż FAT (może oprócz VFAT32, który jest na tym
samym poziomie).
|"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół |
| mailto:rsokol_at_iname.com * http://www.polbox.com/l/lizard/ |
| What do you want to fix today? |
\.........................................................../
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:21:44 MET DST