On Thursday 20 September 2007 11:38, David Chinner wrote: > On Wed, Sep 19, 2007 at 04:04:30PM +0200, Andrea Arcangeli wrote: > > Plus of course you don't like fsblock because it requires work to > > adapt a fs to it, I can't argue about that. > > No, I don't like fsblock because it is inherently a "struture > per filesystem block" construct, just like buggerheads. You > still need to allocate millions of them when you have millions > dirty pages around. Rather than type it all out again, read > the fsblocks thread from here: I don't think there is anything inherently wrong with a structure per filesystem block construct. In the places where you want to have a handle on that information. In the data path of a lot of filesystems, it's not really useful, no question. But the block / buffer head concept is there and is useful for many things obviously. fsblock, I believe, improves on it; maybe even to the point where there won't be too much reason for many filesystems to convert their data paths to something different (eg. nobh mode, or an extent block mapping). > http://marc.info/?l=linux-fsdevel&m=118284983925719&w=2 > > FWIW, with Chris mason's extent-based block mapping (which btrfs > is using and Christoph Hellwig is porting XFS over to) we completely > remove buggerheads from XFS and so fsblock would be a pretty > major step backwards for us if Chris's work goes into mainline. If you don't need to manipulate or manage the pagecache on a per-block basis anyway, then you shouldn't need fsblock (or anything else particularly special) to do higher order block sizes. If you do sometimes need to, then fsblock *may* be a way you can remove vmap code from your filesystem and share it with generic code... > But, I'm not going to argue endlessly for one solution or another; > I'm happy to see different solutions being chased, so may the > best VM win ;) Agreed :) - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
