lkml.org 
[lkml]   [2001]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: linux-2.4.10-pre5
Date
On September 10, 2001 05:02 am, Chris Mason wrote:
> On Monday, September 10, 2001 04:40:21 AM +0200 Daniel Phillips
> <phillips@bonn-fries.net> wrote:
>
> >> How about subsequent calls for the same offset with the same blocksize
> >> need to return the same buffer head?
> >
> > Are we picking nits? Better add "the same dev" and "until the buffer
> > head is freed" ;-)
>
> ;-) Really, wasn't trying for that. If we just say later calls for the
> same offset, we get in trouble later on if we also want variable, very
> large blocksizes.

Well, I really wonder if buffers are the right transport medium for variable,
large blocks, aka extents. Personally, I think buffers will have disappeared
or mutated unrecognizably by the time we get around to adding extents to ext2
or its descendents. Note that XFS already implements extents on Linux, by
mapping them onto the pagecache I believe.

> If we relax the rules to allow multiple buffer heads for
> the same physical spot on disk, things get easier, and the FS is
> responsible for not doing something stupid with it.
>
> The data is still consistent either way, there are just multiple io handles.

Were you thinking of one mapping for all buffers on a given partition? If
so, how did you plan to handle different buffer sizes? Were you planning to
keep the existing buffer hash chain or use the page cache hash chain, as I
did for ext2_getblk?

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.055 / U:34.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site