From: Steven Davies <btrfs-list@steev.me.uk>
To: kreijack@inwind.it
Cc: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
John Petrini <john.d.petrini@gmail.com>,
John Petrini <me@johnpetrini.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Filesystem Went Read Only During Raid-10 to Raid-6 Data Conversion
Date: Thu, 23 Jul 2020 09:57:50 +0100 [thread overview]
Message-ID: <20a7c0211b2d9336b69d48fa5c3d0c5c@steev.me.uk> (raw)
In-Reply-To: <f7771864-9503-646d-dbda-63a43844d230@inwind.it>
On 2020-07-21 21:48, Goffredo Baroncelli wrote:
> On 7/21/20 12:15 PM, Steven Davies wrote:
>> On 2020-07-20 18:57, Goffredo Baroncelli wrote:
>>> On 7/18/20 12:36 PM, Steven Davies wrote:
>>>>>> /dev/sdf, ID: 12
>>>>>> Device size: 9.10TiB
>>>>>> Device slack: 0.00B
>>>>>> Data,RAID10: 784.31GiB
>>>>>> Data,RAID10: 4.01TiB
>>>>>> Data,RAID10: 3.34TiB
>>>>>> Data,RAID6: 458.56GiB
>>>>>> Data,RAID6: 144.07GiB
>>>>>> Data,RAID6: 293.03GiB
>>>>>> Metadata,RAID10: 4.47GiB
>>>>>> Metadata,RAID10: 352.00MiB
>>>>>> Metadata,RAID10: 6.00GiB
>>>>>> Metadata,RAID1C3: 5.00GiB
>>>>>> System,RAID1C3: 32.00MiB
>>>>>> Unallocated: 85.79GiB
>>>>>
>>> [...]
>>>>
>>>> RFE: improve 'dev usage' to show these details.
>>>>
>>>> As a user I'd look at this output and assume a bug in btrfs-tools
>>>> because of the repeated conflicting information.
>>>
>>> What would be the expected output ?
>>> What about the example below ?
>>>
>>> /dev/sdf, ID: 12
>>> Device size: 9.10TiB
>>> Device slack: 0.00B
>>> Data,RAID10: 784.31GiB
>>> Data,RAID10: 4.01TiB
>>> Data,RAID10: 3.34TiB
>>> Data,RAID6[3]: 458.56GiB
>>> Data,RAID6[5]: 144.07GiB
>>> Data,RAID6[7]: 293.03GiB
>>> Metadata,RAID10: 4.47GiB
>>> Metadata,RAID10: 352.00MiB
>>> Metadata,RAID10: 6.00GiB
>>> Metadata,RAID1C3: 5.00GiB
>>> System,RAID1C3: 32.00MiB
>>> Unallocated: 85.79GiB
>>
>> That works for me for RAID6. There are three lines for RAID10 too -
>> what's the difference between these?
>
> The differences is the number of the disks involved. In raid10, the
> first 64K are on the first disk, the 2nd 64K are in the 2nd disk and
> so until the last disk. Then the n+1 th 64K are again in the first
> disk... and so on.. (ok I missed the RAID1 part, but I think the have
> giving the idea )
>
> So the chunk layout depends by the involved number of disk, even if
> the differences is not so dramatic.
Is this information that the user/sysadmin needs to be aware of in a
similar manner to the original problem that started this thread? If not
I'd be tempted to sum all the RAID10 chunks into one line (each for data
and metadata).
>>> Data,RAID6: 123.45GiB
>>> /dev/sda 12.34GiB
>>> /dev/sdb 12.34GiB
>>> /dev/sdc 12.34GiB
>>> Data,RAID6: 123.45GiB
>>> /dev/sdb 12.34GiB
>>> /dev/sdc 12.34GiB
>>> /dev/sdd 12.34GiB
>>> /dev/sde 12.34GiB
>>> /dev/sdf 12.34GiB
>>
>> Here there would need to be something which shows what the difference
>> in the RAID6 blocks is - if it's the chunk size then I'd do the same
>> as the above example with e.g. Data,RAID6[3].
>
> We could add a '[n]' for the profile where it matters, e.g. raid0,
> raid10, raid5, raid6.
> What do you think ?
So like this? That would make sense to me, as long as the meaning of [n]
is explained in --help or the manpage.
Data,RAID6[3]: 123.45GiB
/dev/sda 12.34GiB
/dev/sdb 12.34GiB
/dev/sdc 12.34GiB
Data,RAID6[5]: 123.45GiB
/dev/sdb 12.34GiB
/dev/sdc 12.34GiB
/dev/sdd 12.34GiB
/dev/sde 12.34GiB
/dev/sdf 12.34GiB
--
Steven Davies
next prev parent reply other threads:[~2020-07-23 8:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 16:13 Filesystem Went Read Only During Raid-10 to Raid-6 Data Conversion John Petrini
2020-07-15 1:18 ` Zygo Blaxell
[not found] ` <CADvYWxcq+-Fg0W9dmc-shwszF-7sX+GDVig0GncpvwKUDPfT7g@mail.gmail.com>
[not found] ` <20200716042739.GB8346@hungrycats.org>
2020-07-16 13:37 ` John Petrini
[not found] ` <CAJix6J9kmQjfFJJ1GwWXsX7WW6QKxPqpKx86g7hgA4PfbH5Rpg@mail.gmail.com>
2020-07-16 22:57 ` Zygo Blaxell
2020-07-17 1:11 ` John Petrini
2020-07-17 5:57 ` Zygo Blaxell
2020-07-17 22:54 ` John Petrini
2020-07-18 10:36 ` Steven Davies
2020-07-20 17:57 ` Goffredo Baroncelli
2020-07-21 10:15 ` Steven Davies
2020-07-21 20:48 ` Goffredo Baroncelli
2020-07-23 8:57 ` Steven Davies [this message]
2020-07-23 19:29 ` 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=20a7c0211b2d9336b69d48fa5c3d0c5c@steev.me.uk \
--to=btrfs-list@steev.me.uk \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=john.d.petrini@gmail.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=me@johnpetrini.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.