From: André Fachat (afachat_at_gmx.de)
Date: 2007-08-29 11:26:51
> Von: ruud.baltissen@abp.nl
> > That's exactly the idea behind the "REL"ative files. .....
>
> But is it an elegant solution? IMHO, no. In a previous version of CBM-HD
ah, sorry, I should read the mails in less haste...
of course you are right, if you can calculate the block from
the byte address in the file that of course is the fastest.
As you pointed out, the file must not be fragmented for that.
As this cannot be guaranteed (in general), all filesystems have a
way to look this information up. FAT has its FAT table that you
can scan - basically the CBM link pointers of all blocks put into
one place. Unix filesystems actually are "sidesector" filesystems
(modified, though - the first blocks are kept in the inode (basically
dir entry), then a first level sidesector contains the next block
numbers, then the second level sidesector (super side sector) contains
a list of side sectors etc)
I do have experience implementing FAT12/FAT16 on the CBM, although
it's been a while.
IIRC caching FAT is essential for a good performance. Caching data
blocks as well, but it depends on the access pattern. For a sequential
write you need to cache the (means make a write-back cache) block,
as long as you don't write the full block in one go (i.e. you don't
want to write the block each time after a chunk has been written).
You have to keep book about cache buffer states (dirty/ ..)
if you have more questions, ask please
André
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.