Autor: Rafal Szymczak (rafalszymczak_at_---NO.SPAM---discoverfinancial.com)
Data: Thu 19 Jul 2001 - 22:38:25 MET DST
Grzegorz Szyszlo wrote:
>
> Rafal Szymczak wrote:
>
> > > > Jakie plywanie? Skad masz takie informacje?
> > >
> > > nie powiem ci skad, ale skads to wiem. kiedys tam czytalem jakis
> > > opis HPFS z materialow ibm. ale bylo to wieki temu.
> > > zreszta ta informacja jest posrednio potwierdzona.
> > > na przyklad, jesli plik jest kilka razy z rzedu odczytywany,
> > > to po downie i podniesieniu systemu okazuje sie ze sie czyta
> > > szybciej, konkretnie, mniej jarmoli dyskiem.
> >
> > Moim zdaniem to zaden dowod.
>
> poeksperymentuj na jakims naprawde wolnym dysku, najlepiej ustaw
> go na PIO0 to sam sie przekonasz. dobrze gdyby to byl jakis stary
> dysk, wtedy lepiej slychac co tak naprawde robi.
>
Za wiele dzieje sie "za zaslona", zeby to mial byc wiarygodny dowod.
Jedyny dowod jaki jestem w stanie uznac, to jakis program, ktory by
raportowal fizyczna alokacje dysku dla danego pliku. Wtedy mozna by
stwierdzic fragmentacje przed i po serii odczytow. A tak to tylko
przypuszczenia, zadne konkrety.
> > > no wlasnie to "plywanie". okazuje sie ze jak zapisujesz duzy plik
> > > a dysk jest zfragmentowany, to "wymiata" drobnice w inne wolne miejsce.
> > > jest to szczegolnie zauwazalne przy zapisywaniu ostatnich wolnych
> > > kilobajtow na ok. 2GB partycji, na ktorej jest mnostwo drobnicy.
> > > kasujesz taki plik, i ponownie zapisujesz o takiej samej wielkosci.
> > > przy tej ponownej probie dysk juz tak nie jarmoli. po skasowaniu
> > > i przebootowaniu (zeby nie bylo ze cache), efekt ten sam. mniej jarmoli,
> > > czyli drobnica gdzies "odplynela".
> >
> > Jesli juz, to CHKDSK moze miec cos wspolnego z defragmenterem,
>
> nie. chkdsk tylko sprawdza.
>
> > ale ja
> > upieram sie ze sterownik HPFS nie robi zadnego przesuwania. Wyobraz
> > sobie jak by to spowalnialo operacje na dysku. Wtedy, to FAT bylby
> > szybszy niz HPFS.
>
> no i faktycznie spowalnia. wystarczy plik czytac. jak to jest dlugi
> plik, slychac jak terkocze (polecam do eksperymentow slaby dysk),
> a za drugim razem juz nie terkocze tylko czyta liniowo.
> a to przeciez samo czytanie. plik wiekszy niz 2MB, czyli max
> cache dla HPFS nie 386 :)
>
Jak powyzej, zaden dowod.
> > > gdybym mial pamietac skad wiem to wszystko co mi w glowie siedzi,
> > > wiedzialbym ponad polowe mniej tego co wlasnie wiem.
> >
> > Czyli tzw. pat ("remis" w szachach).
>
> mi tam wszystko jedno czy pat czy nie pat. niby mozna sprawe zbadac
> bardziej doglebnie, tzn. nagrac plik tak by zostal sfragmentowany,
> zdolowac i zamontowac partycje pod linuxem. sprawdzic polozenie
> pliku lub jego fragmentow (support read-only dla linuxa).
> potem czytac plik w kolko az "poplynie" w dogodniejsze miejsce,
> i jeszcze raz sprawdzic. to bylby jednoznaczny werdykt :)
>
> co jeszcze mnie trzyma przy mojej opinii. IBM przy porownaniu
> roznych typow partycji, tzn. FAT, HPFS, HPFS386 i JVS
> zaniza parametry HPFS. ma to chyba jeden sensowny cel, i to
> marketingowy. przekonac klientow by przechodzili na JVS tak
> szybko jak sie da.
Tak? Gdzie to znalazles?
>
> ja np. przylapalem IBM'a na klamstwie, bo spokojnie
> operowalem na plikach 3GB na HPFS, podczas gdy IBM jarmoli
> w zestawieniu ze HPFS obsluguje pliki do 2GB. "very funny"
> ze tak powiem .....
A ja wlasnie przy jednym projekcie odczulem na wlasnej skorze ta
bariere, tak ze wierze ze jest.
>
> ps: ja juz nic wiecej do napisania nie mam :) jedynie demagogia
> mi zostala.
>
W sumie gra nie warta swieczki. Nobla za to nikt nie dostanie.
-- ******************************************* * * * Rafal Szymczak * * Discover Financial Services, Inc. * * rafalszymczak_at_discoverfinancial.com * * "Long live OS/2" * * * *******************************************
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:32:59 MET DST