From: André Fachat (afachat_at_gmx.de)
Date: 2007-08-29 11:26:51
> Von: firstname.lastname@example.org > > 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.