Jaderné noviny - 5. 12. 2007 (diskuse)

[Jan Kundrát (jkt)]

"vyhledat místo za koncem souboru a pak tam zapsat nějaká data" je dosti nestastne, snad spis "presunout interni ukazatel pozice v souboru za jeho konec a pak tam zapsat nejaka data"

[salam]

Kdo nerozuměl tomu prvnímu, ten neporozumí ani tomu druhému

[blah]

to prvni sem nepochopil to druhe jo. to prvni totiz nedava moc smysl

[YYY]

Me se zdaji oboje alternativy celkem stejne srozumitelne :)

[Robert Krátký]

Díky, tak je to lepší.

[filbar]

Nevíte někdo, co je to ten extent? Nějak se mi to nepodařilo pochopit

[Jirka P]

IMHO na filesystémech, co je podporují, jde o něco jako blok, akorát proměnné velikosti. Tzn. kus souboru, který je na disku fyzicky souvislý a na který stačí filesystému jeden záznam. V kontextu toho FIEMAP ale dost možná půjde jen o kus souboru který je na disku souvislý, tzn. n bloků na ext3, které jsou na disku za sebou = jeden extent.

[zde]

Test jestli 4k blok obsahuje samé nuly není přece žádná věda. Když se implementuje efektivně (prefetch, SSE), bude to IMHO zhruba stejně rychlé jako volání té kernelové zbytečnosti :(

[Dan]

Ale volani te kernelove "zbytecnosti" ma slozitost O(1) (zejmena na FS zalozenem na extentech) kdezto seek k dire/datum s hledanim nul ma slozitost O(n).

[zde]

Každé volání kernelu má především velkou fixní režii. Než se přehodí kontexty, načtou registry z userspacu, a provedou ty šílené demultiplexory podle čísla syscallu a podle čísla IOCTL, tak by mohl čistě userspace kód mít blok už dávno schroustaný.

To že jde o O(N) vs O(1) je sice pravda, ale jediné rozumné využití má hledání děr při backupu souborů, čili jako součást O(N) operace, a O(1) + O(N) = O(N). Místo těchto blbostí a nesmyslného bobtnání kernelového API by měli řešit zásadnější věci- třeba konečně zprovoznit suspend, nebo aby wifiny běhaly hned, bez patchování a ndiswrapperu.

[Mordae]

Sorry, ale ja jen kvuli tomuhle ted na Debian nainstaloval vyvojove jadro, protoze me napadla docela pekna aplikace. Co se tyce toho cteni a porovnavani s nulami, obcas je rozdil mezi tim, jestli je to dira, nebo blok nul. Treba kdyz vedome delas copy-on-write nad velkym souborem pomoci sparse-filu. A ano, vim, ze pouzit vlastni vyhledavaci strom asociovany s tim sparse-filem pro oznaceni pouzitych bloku zni taky funkcne, na co ale implementovat neco, co uz jadro beztak dela?

Navic si uvedom, ze jadru staci prozkoumat meta-data a vi, jestli je blok dira nebo ne. Tak jak to navrhujes ty, bych musel cely ten soubor precist, coz je naprosto silene, pokud se bavime o souborech, ktere mohou mit stovky az tisice gigabytu, ale jen nekolik megabytu z toho neni dira.

Takze tak, pekny den.