All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wade Cline <clinew@linux.vnet.ibm.com>
To: miaox@cn.fujitsu.com
Cc: bo.li.liu@oracle.com, linux-btrfs@vger.kernel.org,
	cmm@linux.vnet.ibm.com
Subject: Re: [PATCH] [RFC v2] Btrfs: Subpagesize blocksize (WIP).
Date: Tue, 18 Dec 2012 14:26:50 -0800	[thread overview]
Message-ID: <50D0EDAA.3090202@linux.vnet.ibm.com> (raw)
In-Reply-To: <50D02E0A.8080505@cn.fujitsu.com>

On 12/18/2012 12:49 AM, Miao Xie wrote:

> On tue, 18 Dec 2012 15:30:51 +0800, Liu Bo wrote:
>> On Mon, Dec 17, 2012 at 11:13:25PM -0800, clinew@linux.vnet.ibm.com wrote:
>>> From: Wade Cline<clinew@linux.vnet.ibm.com>
>>>
>>> v1 ->  v2:
>>> - Added Signed-off-by tag (it's kind of important).
>>>
>>> This patch is only an RFC. My internship is ending and I was hoping
>>> to get some feedback and incorporate any suggestions people may
>>> have before my internship ends along with life as we know it (this
>>> Friday).
>>>
>>> The filesystem should mount/umount properly but tends towards the
>>> explosive side when writes start happening. My current focus is on
>>> checksumming issues and also an error when releasing extent buffers
>>> when creating a large file with 'dd'... and probably any other
>>> method. There's still a significant amount of work that needs to be
>>> done before this should be incorporated into mainline.
>>>
>>> A couple of notes:
>>>      - Based off of Josef's btrfs-next branch, commit
>>>        8d089a86e45b34d7bc534d955e9d8543609f7e42
>>>      - C99-style comments are "meta-comments" where I'd like more
>>>        feedback; they aren't permanent but make 'checkpatch' moan.
>>>      - extent_buffer allocation and freeing need their code paths
>>>        merged; they're currently in separate functions and are both
>>>        very ugly.
>>>      - The patch itself will eventually need to be broken down
>>>        into smaller pieces if at all possible...
>>
>> Could you please first elaborate why we need this subpagesize stuff and
>> any user case in this patch's commit log?
>> Or Am I missing something?
>
> It is used on the machines on which the page size is larger than 4KB (Such as powerpc)
>
> Thanks
> Miao

Yeah. Basically, if we create a btrfs filesystem with a 4k blocksize
then that filesystem is incompatible with architectures such as PowerPC
and MIPS which have a page size larger than 4k.

-Wade


  reply	other threads:[~2012-12-18 22:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-18  7:13 [PATCH] [RFC v2] Btrfs: Subpagesize blocksize (WIP) clinew
2012-12-18  7:30 ` Liu Bo
2012-12-18  8:49   ` Miao Xie
2012-12-18 22:26     ` Wade Cline [this message]
2012-12-18 23:01       ` Chris Samuel
2012-12-18 23:19         ` Wade Cline
2012-12-19  2:02       ` Liu Bo
2012-12-19  2:29         ` Wade Cline

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=50D0EDAA.3090202@linux.vnet.ibm.com \
    --to=clinew@linux.vnet.ibm.com \
    --cc=bo.li.liu@oracle.com \
    --cc=cmm@linux.vnet.ibm.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=miaox@cn.fujitsu.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 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.