linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fb.com>
To: Chandra Seetharaman <sekharan@us.ibm.com>,
	<linux-btrfs@vger.kernel.org>, <chandra_pdx@yahoo.com>
Subject: Re: [PATCH 0/7] Patches to support subpagesize blocksize
Date: Fri, 13 Dec 2013 13:39:44 -0500	[thread overview]
Message-ID: <52AB5470.3090108@fb.com> (raw)
In-Reply-To: <1386805122-23972-1-git-send-email-sekharan@us.ibm.com>


On 12/11/2013 06:38 PM, Chandra Seetharaman wrote:
> In btrfs, blocksize, the basic IO size of the filesystem, has been
> more than PAGE_SIZE.
>
> But, some 64 bit architures, like PPC64 and ARM64 have the default
> PAGE_SIZE as 64K, which means the filesystems handled in these
> architectures are with a blocksize of 64K.
>
> This works fine as long as you create and use the filesystems within
> these systems.
>
> In other words, one cannot create a filesystem in some other architecture
> and use that filesystem in PPC64 or ARM64, and vice versa.,
>
> Another restriction is that we cannot use ext? filesystems in these
> architectures as btrfs filesystems, since ext? filesystems have a blocksize
> of 4K.
>
> Sometime last year, Wade Cline posted a patch(http://lwn.net/Articles/529682/).
> I started testing it, and found many locking/race issues. So, I changed the
> logic and created an extent_buffer_head that holds an array of extent buffers that
> belong to a page.
>
> There are few wrinkles in this patchset, like some xfstests are failing, which
> could be due to me doing something incorrectly w.r.t how the blocksize and
> PAGE_SIZE are used in these patched.
>
> Would like to get some feedback, review comments.
>

Ok so the more we talked about it on IRC and talking with Chris I think 
we have a way forward here.

1) Add an extent_buffer_head that embeds an extent_buffer, and in the 
extent_buffer_head track the state of the whole page.  So this is where 
we have a linked list of all the extent_buffers on the page, we can keep 
track of the number of extent_buffers that are dirty/not so we can be 
sure to set the page state and everything right.

2) Set page->private to the first extent_buffer like we currently do.  
Then we just have checks in the endio stuff to see if the eb we found is 
the one for our currently range (ie bv_offset == 0) and if not do a 
linear search through the extent_buffers on the extent_buffer_head part 
to get the right one.

We have to do this because we need to be able to track IO for each of 
the extent_buffer's independently of each other in case a page spans a 
block_group.

Hopefully that makes sense, this way you don't have to futz with any of 
my crazier long term goals of no longer using pagecache or any of that 
mess.  Thanks,

Josef

  parent reply	other threads:[~2013-12-13 18:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11 23:38 [PATCH 0/7] Patches to support subpagesize blocksize Chandra Seetharaman
2013-12-11 23:38 ` [PATCH 1/7] btrfs: subpagesize-blocksize: Define extent_buffer_head Chandra Seetharaman
2013-12-16 12:32   ` saeed bishara
2013-12-16 16:17     ` Chandra Seetharaman
2013-12-17 15:35       ` David Sterba
2013-12-11 23:38 ` [PATCH 2/7] btrfs: subpagesize-blocksize: Use a global alignment for size Chandra Seetharaman
2013-12-16 12:33   ` saeed bishara
2013-12-16 14:48     ` David Sterba
2013-12-16 16:18       ` Chandra Seetharaman
2013-12-11 23:38 ` [PATCH 3/7] btrfs: subpagesize-blocksize: Handle small extent maps properly Chandra Seetharaman
2013-12-11 23:38 ` [PATCH 4/7] btrfs: subpagesize-blocksize: Handle iosize properly in submit_extent_page() Chandra Seetharaman
2013-12-11 23:38 ` [PATCH 5/7] btrfs: subpagesize-blocksize: handle checksum calculations properly Chandra Seetharaman
2013-12-11 23:38 ` [PATCH 6/7] btrfs: subpagesize-blocksize: Handle relocation clusters appropriately Chandra Seetharaman
2013-12-11 23:38 ` [PATCH 7/7] btrfs: subpagesize-blocksize: Allow mounting filesystems where sectorsize != PAGE_SIZE Chandra Seetharaman
2013-12-13  1:07   ` David Sterba
2013-12-16 12:50     ` saeed bishara
2013-12-12 20:40 ` [PATCH 0/7] Patches to support subpagesize blocksize Josef Bacik
2013-12-13  1:17 ` David Sterba
2013-12-13 15:17   ` Chandra Seetharaman
2013-12-13 15:58     ` David Sterba
2013-12-13 18:39 ` Josef Bacik [this message]
2013-12-13 22:09   ` Chandra Seetharaman
2014-01-08 20:06   ` Chandra Seetharaman

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=52AB5470.3090108@fb.com \
    --to=jbacik@fb.com \
    --cc=chandra_pdx@yahoo.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sekharan@us.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).