All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Sanidhya Solanki <jpage.lkml@gmail.com>,
	David Sterba <dsterba@suse.cz>,
	calestyo@scientia.net
Cc: clm@fb.com, jbacik@fb.com, linux-btrfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size
Date: Wed, 30 Dec 2015 19:59:16 +0800	[thread overview]
Message-ID: <5683C714.4040705@gmx.com> (raw)
In-Reply-To: <20151230013946.7c1f0e12@gmail.com>



On 12/30/2015 02:39 PM, Sanidhya Solanki wrote:
> On Tue, 29 Dec 2015 18:06:11 +0100
> David Sterba <dsterba@suse.cz> wrote:
>
>> So you want to make the stripe size configurable?...
>
> As I see it there are 3 ways to do it:
> -Make it a compile time option that only configures it for a single
> system with any devices that are added to the RAID.
> -Make it a runtime option that can change based on how the
> administrator configures it.
> -A non-user facing option that is configurable by someone like a
> distribution maintainer for all systems using the Binary Distribution.

Not really sure about the difference between 2 and 3.

When you mention runtime option, did you mean ioctl/mount/balance 
convert option?

And what's the third one? Default mkfs time option?

If you can make it mkfs time option, it won't be really hard to make it 
configurable.

>
> As I see it, DS would like something like the third option, but CAM
> (ostensibly a SysAdmin) wants the second option.

I didn't consider David means something that.

As far as I read, he means balance convert option along with mkfs option.

>
> On the other hand, I implemented the first option.

At least from what I have learned in recent btrfs development, either we 
provide a good enough interfaces (normally, balance convert ioctl with 
mkfs time option) to configure some on-disk fields.

Or we just leave it to fixed value(normally 0, just like for encryption 
of EXTENT_DATA, and that's the case for current stripe_size).

So fixed kernel value is not a really good idea, and should at least be 
replace by mkfs time option.

>
> The first and third option can co-exit, the second is an orthogonal
> target that needs to be setup separately.
>
> Or we can make all options co-exist, but make it more complicated.

No need.
Just refer to how btrfs kernel handle chunk profile.

It can be specified at mkfs time (by -d and -m options), and can also be 
converted later by balance ioctl. (by btrfs balance convert filter).

The only tricky thing I am a little considered about is, how do we keep 
the default chunk stripe size for a fs.

Thanks,
Qu
>
> Please let me know which implementation is preferable, and, if you just
> want me to expand the description (as DS' mail asked for) or redo the
> entire setup.
>
> 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:[~2015-12-30 12:00 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
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 [this message]
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=5683C714.4040705@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=calestyo@scientia.net \
    --cc=clm@fb.com \
    --cc=dsterba@suse.cz \
    --cc=jbacik@fb.com \
    --cc=jpage.lkml@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@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.