[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: > > On Saturday 03 January 2009 06:38:07 Chris Mason wrote: > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
