Subject: Re: File > 2G on a dvd
To: Wolfgang Solfrank <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 12/02/2004 00:02:15
In article <41AB69AE.email@example.com>,
firstname.lastname@example.org (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...
188.8.131.52 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/184.108.40.206.
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.