Quoting Bill Stouder-Studenmund <wrstuden@netbsd.org>:

> On Sun, Jul 01, 2007 at 03:01:44PM -0400, Thor Lancelot Simon wrote:
>
>> I would not be displeased if you changed the buffer cache code so that
>> this were no longer the case, and I doubt anyone else would either.
>
> I doubt anyone would mind. However all the file systems we have get this
> right, so not much would need it. Also, the main direction (I think) for
> caching is UBC. All that's in the buffer cache is metadata.

EFS doesn't do things properly at present, but it doesn't trigger this  
error, and I could easily make it conform.

In any event, I'd either like to fix this so it behaves as expected,  
or update the documentation and add some assertions so people don't  
trip over this in the future.

The following makes things behave as I had expected. Whether this is  
complete or correct is beyond my present knowledge to appropriately  
judge.

--- vfs_bio.c   17 May 2007 14:51:42 -0000      1.172
+++ vfs_bio.c   3 Jul 2007 14:13:12 -0000
@@ -1081,6 +1081,8 @@
         if (ISSET(bp->b_flags, B_LOCKED)) {
                 KASSERT(bp->b_bufsize >= size);
         } else {
+               if (size > bp->b_bcount)
+                       CLR(bp->b_flags, B_DONE);
                 allocbuf(bp, size, preserve);
         }
         BIO_SETPRIO(bp, BPRIO_DEFAULT);

It's also not terribly efficient, triggering a re-read of any  
overlapping region. Also, I suppose if buffers were to overlap while  
not beginning from the same offset, we'd have duplication and  
terrible, unexpected things could happen.

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?

Thanks for the replies,
Steve