On Thu, Mar 20, 2014 at 08:50:27AM +0530, Aneesh Kumar K.V wrote: > > On Tue, Mar 18, 2014 at 01:48:00PM +0630, chandan wrote: > >> The earlier patchset posted by Chandra Seethraman was to get 4k > >> blocksize to work with ppc64's 64k PAGE_SIZE. > > > > Are we talking about metadata block sizes or data block sizes? > > > >> The root node of "tree root" tree has 1957 bytes being written by > >> make_btrfs() (in btrfs-progs). Hence I chose to do 2k blocksize for > >> the initial subpagesize-blocksize work. So with this patchset the > >> supported blocksizes would be in the range 2k-64k. > > > > So it's metadata blocks, and in this case 2k looks like the only > > allowed size that's smaller than 4k, and thus can demonstrage sub-page > > size allocations. I'm not sure if this is limiting for potential future > > extensions of metadata structures that could be larger. > > > > 2k is ok for testing purposes, but I think a 4k-page machine will hardly > > use a smaller page size. The more that 16k metadata blocks are now > > default. > > The goal is to remove the assumption that supported blocks size is >= page > size. The primary reason to do that is to support migration of disk > devices across different architectures. If we have a btrfs disk created > on x86 box with data blocksize 4K and meta data block size 16K we should > make sure that, the disk can be read/written from ppc64 box (which have a page > size of 64K). To enable easy testing and community development we are > now focusing on achieving 2K data blocksize and 2K meata data block size > on x86. As you said this will never be used in production. > > To achieve that we did the below > *) Add offset and len to btrfs_io_bio. These are file offsets and > len. This is later used to unlock extent io tree. > > *) Now we also need to make sure that submit_extent_page only submit > contiguous range in the file offset range. ie if we have holes in > between we split them into two submit_extent_page. This ensures that > btrfs_io_bio offset and len represent a contiguous range. > > Please let us know whether the above approach is acceptable. I don't see any apparent problem with this approach. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
