In article <41AB69AE.4090201@tools.de>,
	ws@tools.de (Wolfgang Solfrank) writes:
> 
>> Not knowing the ins and outs of the filesystem code, I can't think why
>> any fs independent code would need a byte offset <-> relative block
>> number conversion. Any place where that is seriously used would be
>> inside the specific filesystem code itself?
> 
> Well, there are various things that come into play here.  There actually
> _is_ no interface where fs independent code could ask the filesystem what
> was the relative block number of some byte offset.  But the buffer cache
> is only buffering full blocks, and it is caching those as file relative
> blocks, not filesystem relative ones (maybe this has changed with ubc?
> probably not much, but I'd have to look), so it does determine the file
> relative block number by division of the file offset.

Suppose we just assume that partial blocks won't occur in the middle of a
file? OSTA's UDF 2.50 has this to say...

 2.3.6.4 Uint64 InformationLength
  Only the last extent of the file body may have an extent length that is
  not a multiple of the block size, see ECMA 167 4/12.1 and 4/14.14.1.1.

so recalling that we're only invoking "level 3" to permit the full size of
a file in the UDF part to be expressed in the ISO 9660 part, a more
permissive implementation in the kernel would have no practical value. The
worst consequence of ignoring the general case, is that such a strange file
would be read as having a few bytes of garbage in the middle of it.


Frederick