Hi,

David Laight wrote:
> On Mon, Oct 10, 2005 at 06:46:50PM +0200, Wolfgang Solfrank wrote:
> 
>>The problem currently is that with 9660, a file can have multiple extents,
>>which can have arbitray lengths, i.e. need not be multiples of the block/
>>sector size.  The current vfs interface doesn't allow for that.  Changing
>>it to use byte offsets instead would be really useful here.
> 
> 
> Are you sure that is allowed to happen?

Yes, I'm sure that it is allowed.  The file would have several directory
entries, 1 per extent.  And any extent can have an arbitray length with
byte granularity.

This allows e.g. extending logfiles on multisession CDs.  After writing the
first session with the then current logfile, you can later write a second
session, which will generate a new directory structure.  The logfile gets 2
directory entries, with the first one just a copy of the one from the first
session (including pointing to the data on the first session) and the second
one pointing to the new part of the logfile (i.e., the second session only
actually contains the additional data).

> The media may well constain the FS to 2k sectors, even though the FS itself
> allows byte sized extents.

Well, the only constraint(s) is(are) the various implementations of the FS.

> Certainly the low-level format for cdroms has 2k blocks of ecc data within
> the 25xx byte audio sector (which itself has some error correction).
> So I wouldn't expect byte-sized extents.

This isn't relevant either.  The actual blocks are all 2k as far as 9660
is concerned (actually, they may have some other power of 2 block size
between 2k and 32k AFAIR, would have to dig up the specification for that).
The extent size is only a logical thing in the FS interpretation.  I.e., the
remainder of the last block of an extent is simply ignored.

Ciao,
Wolfgang
-- 
ws@TooLs.DE                            Wolfgang Solfrank, TooLs GmbH