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