All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: chandan <chandan@linux.vnet.ibm.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/6 EARLY RFC] Btrfs: Get rid of whole page I/O.
Date: Thu, 3 Apr 2014 19:01:34 +0200	[thread overview]
Message-ID: <20140403170134.GN29256@suse.cz> (raw)
In-Reply-To: <87a9climis.fsf@linux.vnet.ibm.com>

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.

      reply	other threads:[~2014-04-03 17:01 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
2014-04-03 17:01         ` David Sterba [this message]

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=20140403170134.GN29256@suse.cz \
    --to=dsterba@suse.cz \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=chandan@linux.vnet.ibm.com \
    --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.