On Sun, Jan 24, 2010 at 09:59:09PM +0100, Wolfgang Solfrank wrote: >>> As an extreme example [on ISO 9660], you could have a file with 3 bytes, >>> where every byte is in a separate block. >> Raising the question of which kind of resource limitation exactly you want >> to impose on the user. Wouldn't it make sense to count that kind of usage >> as three blocks? After all, it's disc blocks you run out of, not bytes of >> user data. > > I'm not sure why you bring up quota in this discussion.
Someone else mentioned the on-disk FFS quota format. However, this is not relevant to cd9660. > The problem I tried to describe is that the current buffer cache > with its DEV_BSIZE centric implementation more or less forbids any > implementation of this part of the 9660 specification (albeit I have > to admit that last I looked into this was before UBC integration.) > A buffer cache that works with byte offsets and byte sizes of > buffers would simplify this tremendously It's both not quite that bad and worse. Buffer cache buffers can be whatever size; they are normally the FS block size and they certainly aren't limited to DEV_BSIZE. However, the API is such that if any one file system's buffers aren't all the same size it's treading on very thin ice. This should be rectified sometime. The address to read from is also a block number, but the buffer code does not (as far as I know) itself interpret this number but just passes it along. -- David A. Holland dholl...@netbsd.org
