Re: Question: how understand the raid profile of a btrfs filesystem

Goffredo Baroncelli
2020-03-23T20:50:08Z

On 3/23/20 12:49 AM, Zygo Blaxell wrote:
> On Sun, Mar 22, 2020 at 09:38:30AM +0100, Goffredo Baroncelli wrote:
>> On 3/22/20 9:34 AM, Goffredo Baroncelli wrote:
>>
>>>
>>> To me it seems complicated to
>> [sorry I push the send button too early]
>>
>> To me it seems too complicated (and error prone) to derive the target profile from an analysis of the filesystem.
>>
>> Any thoughts ?
>
> I still don't understand the use case you are trying to support.
>
> There are 3 states for a btrfs filesystem:
>
[...]
>
> 3. A conversion is interrupted prior to completion. Sysadmin is
> expected to proceed immediately back to state #2, possibly after
> taking any necessary recovery actions that triggered entry into
> state #3. It doesn't really matter what the current allocation
> profile is, since it is likely to change before we allocate
> any more block groups.
>
> You seem to be trying to sustain or support a filesystem in state #3 for
> a prolonged period of time. Why would we do that? If your use case is
> providing information or guidance to a user, tell them how to get back
> to state #2 ASAP, so that they can then return to state #1 where they
> should be.

Believe me: I *don't want* to sustain #3 at all; btrfs is already too
complex. Supporting multiple profile is the worst thing that we can do.
However #3 exists and it could cause unexpected results. I think that on
this we agree.
>
[...]

> There could be a warning message in dmesg if we enter state #3.
> This message would appear after a converting balance is cancelled or
> aborted, and on mount when we scan block groups (which we would still need
> to do even after we added a "target profile" field to the superblock).
> Userspace like 'btrfs fi df' could also put out a warning like "multiple
> allocation profiles detected, but conversion is not in progress. Please
> finish conversion at your earliest convenience to avoid disappointment."
> I don't see the need to do anything more about it.

It would help that every btrfs command should warn the users about an
"un-wanted" state like this.

>
> We only get to state #3 if the automation has already failed, or has
> been explicitly cancelled at sysadmin request.
>
Not only, you can enter in state #3 if you do something like:

$ sudo btrfs balance start -dconvert=single,usage=50 t/.

where you convert some chunk but not other.

This is the point: we can consider the "failed automation" an unexpected
event, however doing "btrfs bal stop" or the command above cannot be
considered as unexpected event.

[...]

> I'd even consider removing the heuristics that are already there for
> prioritizing profiles. They are just surprising and undocumented
> behavior, and it would be better to document it as "random, BTW you
> should finish your conversion now."

I agree that we should remove this kind of heuristic.
Doing so I think that, with moderate effort, btrfs can track what is the
wanted profile (i.e. the one at the mkfs time or the one specified in last balance
w/convert [*]) and uses it. To me it seems the natural thing to do. Noting more
nothing less.
We can't prevent a mixed profile filesystem (it has to be allowed the
possibility to stop a long activity like the balance), but we should
prevent the unexpected behavior: if we change the profile and something
goes wrong, the next chunk allocation should be clear. The user don't have
to read the code to understand what will happen.
[*] we can argue which would be the expected profile after an interrupted balance:
the former one or the latter one ?

BR
G.Baroncelli

--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5