All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Qu Wenruo <quwenruo.btrfs@gmx.com>,
	David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: allow degenerate raid0/raid10
Date: Sat, 24 Jul 2021 06:35:31 +0800	[thread overview]
Message-ID: <808c7591-6bd7-882d-63d7-a1c25f3e1833@gmx.com> (raw)
In-Reply-To: <20210723140843.GE19710@twin.jikos.cz>



On 2021/7/23 下午10:08, David Sterba wrote:
> On Fri, Jul 23, 2021 at 06:51:31AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2021/7/23 上午3:29, David Sterba wrote:
>>> The data on raid0 and raid10 are supposed to be spread over multiple
>>> devices, so the minimum constraints are set to 2 and 4 respectively.
>>> This is an artificial limit and there's some interest to remove it.
>>
>> This could be a better way to solve the SINGLE chunk created by degraded
>> mount.
>
> Yes, but in this case it's rather a conicidence because raid0 now
> becomes a valid fallback profile, other cases are not affected. There's
> also some interest to allow full write with missing devices (as long as
> complete data can be written, not necessarily to all copies). MD-RAID
> allows that.
>
> As an example, when we'd allow that, 2 device raid1 with one missing
> will continue to write to the present device and once the missing device
> reappears, scrub will fill the missing bits, or device replace will do a
> full sync.
>
>>> Change this to allow raid0 on one device and raid10 on two devices. This
>>> works as expected eg. when converting or removing devices.
>>>
>>> The only difference is when raid0 on two devices gets one device
>>> removed. Unpatched would silently create a single profile, while newly
>>> it would be raid0.
>>>
>>> The motivation is to allow to preserve the profile type as long as it
>>> possible for some intermediate state (device removal, conversion).
>>>
>>> Unpatched kernel will mount and use the degenerate profiles just fine
>>> but won't allow any operation that would not satisfy the stricter device
>>> number constraints, eg. not allowing to go from 3 to 2 devices for
>>> raid10 or various profile conversions.
>>
>> My initial thought is, tree-checker will report errors like crazy, but
>> no, the check for RAID1 only cares substripe, while for RAID0 no number
>> of devices check.
>>
>> So a good surprise here.
>>
>> Another thing is about the single device RAID0 or 2 devices RAID10 is
>> the stripe splitting.
>>
>> Single device RAID0 is just SINGLE, while 2 devices RAID10 is just RAID1.
>> Thus they need no stripe splitting at all.
>>
>> But we will still do the stripe calculation, thus it could slightly
>> reduce the performance.
>> Not a big deal though.
>
> Yeah effectively they're raid0 == single, raid10 == raid1, I haven't
> checked the overhead of the additional striping logic nor measured
> performance impact but I don't feel it would be noticeable.
>
>>> Example output:
>>>
>>>     # btrfs fi us -T .
>>>     Overall:
>>>         Device size:                  10.00GiB
>>>         Device allocated:              1.01GiB
>>>         Device unallocated:            8.99GiB
>>>         Device missing:                  0.00B
>>>         Used:                        200.61MiB
>>>         Free (estimated):              9.79GiB      (min: 9.79GiB)
>>>         Free (statfs, df):             9.79GiB
>>>         Data ratio:                       1.00
>>>         Metadata ratio:                   1.00
>>>         Global reserve:                3.25MiB      (used: 0.00B)
>>>         Multiple profiles:                  no
>>>
>>> 		Data      Metadata  System
>>>     Id Path       RAID0     single    single   Unallocated
>>>     -- ---------- --------- --------- -------- -----------
>>>      1 /dev/sda10   1.00GiB   8.00MiB  1.00MiB     8.99GiB
>>>     -- ---------- --------- --------- -------- -----------
>>>        Total        1.00GiB   8.00MiB  1.00MiB     8.99GiB
>>>        Used       200.25MiB 352.00KiB 16.00KiB
>>>
>>>     # btrfs dev us .
>>>     /dev/sda10, ID: 1
>>>        Device size:            10.00GiB
>>>        Device slack:              0.00B
>>>        Data,RAID0/1:            1.00GiB
>>
>> Can we slightly enhance the output?
>> RAID0/1 really looks like a new profile now, even the "1" really means
>> the number of device.
>
> Do you have a concrete suggestion? This format was inspired by a
> discussion and suggested by users so I guess this is what people expect
> and I find it clear. It's also documented in manual page so if you think
> it's not clear or missing some important information, please let me
> know.

My idea may not be pretty though:

         Data,RAID0 (1 dev):            1.00GiB

As if we follow the existing pattern, it can be more confusing like:

         Data,RAID5/6

Thanks,
Qu

  parent reply	other threads:[~2021-07-23 22:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22 19:29 [PATCH] btrfs: allow degenerate raid0/raid10 David Sterba
2021-07-22 22:51 ` Qu Wenruo
2021-07-23 14:08   ` David Sterba
2021-07-23 17:27     ` Roman Mamedov
2021-07-23 19:21       ` David Sterba
2021-07-24 11:04         ` waxhead
2021-07-24 11:24           ` Hugo Mills
2021-07-24 11:49             ` waxhead
2021-07-24 11:55               ` Hugo Mills
2021-07-24 12:07                 ` waxhead
2021-07-24 12:30           ` Hugo Mills
2021-07-24 13:54             ` Forza
2021-07-24 21:15               ` Zygo Blaxell
2021-07-24 22:25             ` waxhead
2021-07-23 22:35     ` Qu Wenruo [this message]
2021-07-24 21:31   ` Zygo Blaxell

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=808c7591-6bd7-882d-63d7-a1c25f3e1833@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --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.