generic pagecache to block mapping layer (was Re: Btrfs for mainline)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux