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

Zygo Blaxell
2020-03-22T23:49:36Z

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:

1. All block groups use the same profile. Pick any one,
use its profile for future block groups. Avoid deleting the
last one. Simple and easy to implement.

2. A conversion is in progress. Look in fs_info->balance_ctl
for a 'convert' filter. If there is one, that's the profile for
new block groups. Old block groups will be emptied and destroyed
by conversion, and then we automatically go back to state #1.

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.

Suppose your use case does involve staying in state #3 for a prolonged
period of time--let's say e.g. you want to be able to use file attributes
to put some file data on single profile while putting other files on raid5
profile. That use case would need to come with a bunch of infrastructure
to support it, i.e. you'd need to define what the attributes are, and
how btrfs could map those to device subsets and raid profiles. None of
this exists, and even if it did, it would conflict with the "store the
[singular] target profile on disk" idea.

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.

We only get to state #3 if the automation has already failed, or has
been explicitly cancelled at sysadmin request. It is better to wait
for the sysadmin to decide what to do next, especially if the sysadmin's
prior choice led to us entering this state (e.g. not enough space to
complete a conversion to the target profile, so we can no longer use
the target profile for new allocations). Picking a target profile
at random (from the set of profiles already used in the filesystem)
is no better or worse than any deterministic algorithm--it will always
be wrong in some situations, and a good choice in other situations.

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." It doesn't help if e.g. you
want to convert from raid6 to raid1, since the heuristic assumes you
only want to go the other way.

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