On Tue, 2007-10-16 at 12:36 +1000, David Chinner wrote: > On Mon, Oct 15, 2007 at 08:22:31PM -0400, Chris Mason wrote: > > Hello everyone, > > > > I'm stealing the cc list and reviving and old thread because I've > > finally got some numbers to go along with the Btrfs variable blocksize > > feature. The basic idea is to create a read/write interface to > > map a range of bytes on the address space, and use it in Btrfs for all > > metadata operations (file operations have always been extent based). > > > > So, instead of casting buffer_head->b_data to some structure, I read and > > write at offsets in a struct extent_buffer. The extent buffer is very > > small and backed by an address space, and I get large block sizes the > > same way file_write gets to write to 16k at a time, by finding the > > appropriate page in the addess space. This is an over simplification > > since I try to cache these mapping decisions to avoid using too much > > CPU, but hopefully you get the idea. > > > > The advantage to this approach is the changes are all inside Btrfs. No > > extra kernel patches were required. > > > > Dave reported that XFS saw much higher write throughput with large > > blocksizes, but so far I'm seeing the most benefits during reads. > > Apples to oranges, Chris ;) > Grin, if the two were the same, there'd be no reason to write a new one. I didn't expect faster writes on btrfs, at least not for workloads that did not require reads. The basic idea is to show there are a variety of ways the larger blocks can improve (and hurt) performance. Also, vmap isn't the only implementation path. Its true the Btrfs changes for this were huge, but a big chunk of the changes were for different leaf/node blocksizes, something that may never get used in practice. -chris - 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
