[trim ccs]

Feel free to ignore this diversion ;) I'd like to see btrfs go upstream
sooner rather than later. But eventually we'll have to resurrect fsblock
vs extent map discussion.

On Tuesday 06 January 2009 00:21:43 Chris Mason wrote:

On Mon, 2009-01-05 at 21:32 +1100, Nick Piggin wrote:

quoted

On Saturday 03 January 2009 06:38:07 Chris Mason wrote:

quoted

The extent_map and extent_buffer code was also intended for generic
use. It needs some love and care (making it work for blocksize !=
pagesize) before I'd suggest moving it out of fs/btrfs.

I'm yet to be convinced it is a good idea to use extents for this. Been a
long time since we visited the issue, but when you converted ext2 to use
the extent mapping stuff, it actually went slower, and complexity went up
a lot (IIRC possibly required allocations in the writeback path).


So I think it is a fine idea to live in btrfs until it is more proven and
found useful elsewhere.

It has gotten faster since then, but it makes sense to wait on moving
extent_* code.

faster, than it was or than buffer heads now?

fsblock is faster than buffer heads, robust WRT memory allocation,
supports smaller and larger blocks than pagecache, and does locking
solely on a per-page basis.

I added a module that can cache block mapping (but not pagecache state
mapping, importantly) in extents for filesystems that don't have a good
in-memory data structure (although this has a per-inode lock course). I
agree that using extents for this makes perfect sense, but I've just
never thought pagecache state extents are a good idea.

I don't think this will be too easy to beat with state extents. I
haven't looked closely at your implementation for quite a while, but
last I did, I couldn't imagine it being easy to make fast+scalable or
rework it to have good memory allocation behaviour.