All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Sanidhya Solanki <jpage.lkml@gmail.com>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: David Sterba <dsterba@suse.cz>, <jbacik@fb.com>,
	<linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size
Date: Mon, 11 Jan 2016 09:29:02 +0800	[thread overview]
Message-ID: <5693055E.5010207@cn.fujitsu.com> (raw)
In-Reply-To: <20160109221105.6b18fb8e@gmail.com>



Sanidhya Solanki wrote on 2016/01/09 22:11 -0500:
> On Sun, 3 Jan 2016 09:37:04 +0800
> Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> Btrfs checksum are calculated in 3 different method:
>> 1) Metadata: Per nodesize, stored in tree blocker header. (struct
>> btrfs_header->csum)
>> 2) Data: Per sectorsize, stored in csum tree.
>> 3) Superblock: Per 4K (fixed), stored in its header (struct
>> btrfs_super->csum)
>>
>> I didn't the need to change any of them, as you are not changing any
>> of the csum behavior.
>
> Good, that means I do not need to compare csums, just the data at the
> end of the re-sizing operation.
>
> I have finished most of the actual implementation details and
> documentation for the re-size. However, before I undertake the last
> part of the development, the integration of kernel-space and user-space,
> as well as the integration between my code and the kernel code.
>
>> Stripe size only affect how btrfs does IO, not the csum size.
>
> I have a question regarding this statement. I wanted to confirm that
> the re-size will result in all the data blocks being re-written. Is
> that correct?

AFAIK, Yes for stripe based RAID profile.

And I must admit that, the above statement is not completely right.
It also affect the on-disk data layout. But csum is still not affected.

> Because the single statement above may also mean that all that needs to
> be done is change one option and the kernel code takes care of the rest.
>
> Just clarify that for me.
>
>> And since you are making the stripe size configurable, then user is
>> responsible for any too large or too small stripe size setting.
>
> I have also left the option to use an un-conventional stripe size to the
> user, for e.g., 768, 3072, 6144, etc.

Although personally I prefer to restrict to power of 2, but that's a 
personal choice anyway.

Thanks,
Qu

>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>



  reply	other threads:[~2016-01-11  1:29 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-28 12:24 [PATCH] BTRFS: Adds an option to select RAID Stripe size Sanidhya Solanki
2015-12-28 22:19 ` Christoph Anton Mitterer
2015-12-28 20:38   ` Sanidhya Solanki
2015-12-29  1:21     ` Christoph Anton Mitterer
2015-12-28 21:43       ` Sanidhya Solanki
2015-12-29  3:42         ` Christoph Anton Mitterer
2015-12-29  0:03           ` Sanidhya Solanki
2015-12-29  4:26             ` Christoph Anton Mitterer
2015-12-29  1:31               ` Sanidhya Solanki
2015-12-29  6:03                 ` Christoph Anton Mitterer
2015-12-29  2:23                   ` Sanidhya Solanki
2015-12-29 15:32                     ` Christoph Anton Mitterer
2015-12-29 16:44                       ` Duncan
2015-12-30  2:56                         ` Christoph Anton Mitterer
2015-12-29 18:06               ` David Sterba
2015-12-30 20:00                 ` Christoph Anton Mitterer
2015-12-30 21:02                   ` Duncan
2015-12-30 21:13                     ` Christoph Anton Mitterer
2016-01-02 11:52                 ` Sanidhya Solanki
2016-01-03  1:37                   ` Qu Wenruo
2016-01-03  2:26                     ` Christoph Anton Mitterer
2016-01-05 10:44                       ` David Sterba
2016-01-05 18:48                         ` Christoph Anton Mitterer
2016-01-10  3:11                     ` Sanidhya Solanki
2016-01-11  1:29                       ` Qu Wenruo [this message]
2016-01-11 15:43                       ` Christoph Anton Mitterer
2016-01-11 11:49                         ` Sanidhya Solanki
2016-01-11 15:57                           ` Christoph Anton Mitterer
2016-01-11 16:01                             ` Hugo Mills
2016-01-12 12:23                             ` Austin S. Hemmelgarn
2016-01-12 12:07                               ` Sanidhya Solanki
2015-12-29 13:39 ` David Sterba
2015-12-29 11:15   ` Sanidhya Solanki
2015-12-29 17:06     ` David Sterba
2015-12-29 21:32       ` Sanidhya Solanki
2015-12-30  6:39       ` Sanidhya Solanki
2015-12-30 11:59         ` Qu Wenruo
2015-12-30  9:54           ` Sanidhya Solanki
2015-12-30 14:10             ` Qu Wenruo
2015-12-30 11:15               ` Sanidhya Solanki
2015-12-30 15:58                 ` David Sterba
2015-12-30 21:19                   ` Sanidhya Solanki
2015-12-30 16:17               ` David Sterba
2015-12-30 21:21                 ` Sanidhya Solanki
2016-01-05 10:33                   ` David Sterba
2015-12-31  0:46                 ` Qu Wenruo
2016-01-05 10:16                   ` David Sterba
2015-12-30 19:48               ` Christoph Anton Mitterer

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=5693055E.5010207@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=dsterba@suse.cz \
    --cc=jbacik@fb.com \
    --cc=jpage.lkml@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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.