Subject: Re: Overlapping bread(9) behaviour
To: None <tls@rek.tjls.com>
From: Stephen M. Rumble <stephen.rumble@utoronto.ca>
List: tech-kern
Date: 07/03/2007 11:55:17
Quoting Thor Lancelot Simon <tls@rek.tjls.com>:
> On Tue, Jul 03, 2007 at 10:18:55AM -0400, Stephen M. Rumble wrote:
>>
>> In any event, I'd either like to fix this so it behaves as expected,
>
> What is "as expected"? It works the way the Unix buffer cache always has.
"As expected" is my interpretation of what bread(9) says. It makes no
mention that what I was previously attempting to do is invalid. The
system also makes no attempt to assert that it's being used properly
in this regard. I think that a note in the manual and an assertion
would be appropriate.
>> A few related questions: If the buffer cache expects fixed-sized
>> buffers, does that mean for some filesystems there could be a 124-byte
>> struct buf for each block of cached data? Also, do we not have any
>> filesystems with extents where this sort of thing would have cropped
>> up before?
>
> You understand that actual file data is not cached through the buffer
> cache, yes? If EFS is doing so, EFS is buggy. The buffer cache is only
> used for metadata now -- the page cache handles all else.
No, I did not understand this very well. I should update the
documentation to express this.
This clarifies things a fair bit. I was wondering how UBC could work
if the routines in vfs_bio.c pre-allocated a fixed amount of buffer
memory. I was also confused as to how mmaped operations maintained
consistency with the buffer cache.
EFS does not use the buffer cache for VREG. It does, however, for VDIR
and VLNK. I think this is appropriate. Kindly correct me if I'm wrong.
> We don't have any filesystems that use extents -- the clustering done by
> FFS is the closest thing to that, really, and that's now handled by the
> paging code. When it was done through the buffer cache... sigh... do
> you _really_ want to know?
Sounds like an ordeal. I won't push it ;) I'm curious, though there
are always the CVS logs.
Thanks again, Thor.
Steve