Autor: Rafal Szymczak (rafalszymczak_at_---NO.SPAM---discoverfinancial.com)
Data: Mon 23 Jul 2001 - 19:02:05 MET DST
Grzegorz Szyszlo wrote:
>
> Rafal Szymczak wrote:
> > > 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.
>
> przy takim podejsciem, nawet oficjalny komunikat ze strony IBM
> nie jest dowodem, bo .... mozna sugerowac ze opisuje zupelnie inna
> wersje implementacji HPFS :)
>
Ale to jest bardziej wiarygodne zrodlo niz wlasne domysly.
> > > 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?
>
> jeden z grupowiczow wyciagnal info z materialow IBM i przyslal
> na grupe. trzeba by przeczesac archiwum. mi sie nie chce :)
> ale na 100% bylo.
> watek dotyczyl plikow wiekszych niz 2GB oraz JVS.
>
JFS (Journaled File System) jesli juz, a nie JVS. Pomylilo Ci sie cos z
LVM (Logical Volume Manager).
Byc moze ze zachecaja, ale pewnikiem ze wzgledu na royalties (jak to
bedzie po polsku?), ktore IBM musi placic do Micro$oft za HPFS386.
Niestety, M$ ma duze prawa do originalnego kodu HPFS386, ktory nadal
jest obecny.
> > > 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.
>
> mozliwe ze to byl problem implementacji jezyka ktorego uzywales.
> ja sprawdzilem za pomoca wbudowanego REXX. zapisywalem 8bajtowe
> paczki, w ktorych byla zapisana jedna liczba, offset od poczatku
> pliku. czytalem liniowo, bylo ok. na wyrywki, ok. stwierdzilem
> ze HPFS przynajmniej do ok. 3GB (podejrzewam ze do 4GB)
> ograniczenia nie ma. a konkretne jezyki/kompilatory moga miec
> ograniczenia, bo operuja na 4rech bajtach ze znakiem.
Nic podobnego. Program byl napisany w C i tylko zapisywal, nic nie
czytal. Przy okolo 2 GB pliku zaczalem dostawac bledy przy zapisie do
pliku. Ponizej jest fragment programu kompilowany VAC-kiem. Choc czasem
sie zdarzalo, ze plik utworzony przekraczal nieznacznie granice 2 GB, to
nigdy nie wyszedl poza nia o wiecej niz pare MB.
fpout = fopen( szOutputFile, "a" );
[ciach]
case AE_NETLOGOFF:
pNetLogoff = ( struct ae_netlogoff * ) ( ( PCHAR )
pEntry + pEntry->ae_data_offset );
if ( !pNetLogoff->ae_nf_username )
pNetLogoff->ae_nf_username =
pNetLogoff->ae_nf_compname;
fprintf( fpout, "%-15.15s %s ", szServer, ExtrTimeStamp(
&pEntry->ae_time ) );
fprintf( fpout, "%-15.15s %-20.20s",
( PSZ ) pNetLogoff +
pNetLogoff->ae_nf_compname,
CleanString( ( PSZ ) pNetLogoff +
pNetLogoff->ae_nf_username ) );
iRC = fprintf( fpout, " %s\n", szTimeStamp ); <=== ***
tu sie wywalal ***
if ( iRC <= 0 )
{
sprintf( szMsgBuf, "%s Failed to write to the output
file. rc = %d", szServer, iRC );
printf( "\n\n%s\n\n\a", szMsgBuf );
WriteError( szMsgBuf );
fclose( fpout );
fclose( fperr );
exit( 5 );
}
break;
-- ******************************************* * * * 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:33:06 MET DST