All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: dsterba@suse.cz, chandan <chandan@linux.vnet.ibm.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/6 EARLY RFC] Btrfs: Get rid of whole page I/O.
Date: Thu, 20 Mar 2014 08:50:27 +0530	[thread overview]
Message-ID: <87a9climis.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140319184107.GJ29256@suse.cz>

David Sterba <dsterba@suse.cz> writes:

> 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.

 -aneesh
 


  reply	other threads:[~2014-03-20  3:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 14:20 [PATCH 0/6 EARLY RFC] Btrfs: Get rid of whole page I/O Chandan Rajendra
2014-03-12 14:20 ` [PATCH 1/6] Btrfs: subpagesize-blocksize: Get rid of whole page reads Chandan Rajendra
2014-03-19  7:37   ` Liu Bo
2014-03-19 15:50     ` chandan Rajendra
2014-03-12 14:20 ` [PATCH 2/6] Btrfs: subpagesize-blocksize: Get rid of whole page writes Chandan Rajendra
2014-03-12 14:20 ` [PATCH 3/6] Btrfs: subpagesize-blocksize: Work with extents aligned to blocksize Chandan Rajendra
2014-03-12 14:20 ` [PATCH 4/6] Btrfs: subpagesize-blocksize: Define extent_buffer_head Chandan Rajendra
2014-03-12 14:20 ` [PATCH 5/6] Btrfs: subpagesize-blocksize: Hardcode MAX_EXTENT_BUFFERS_PER_PAGE to 2 Chandan Rajendra
2014-03-12 14:20 ` [PATCH 6/6] Btrfs: subpagesize-blocksize: Allow mounting filesystems where sectorsize != PAGE_SIZE Chandan Rajendra
2014-03-17 14:55 ` [PATCH 0/6 EARLY RFC] Btrfs: Get rid of whole page I/O David Sterba
2014-03-18  7:18   ` chandan
2014-03-19 18:41     ` David Sterba
2014-03-20  3:20       ` Aneesh Kumar K.V [this message]
2014-04-03 17:01         ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a9climis.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.