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

Graham Cobb
2020-03-23T22:49:04Z

On 23/03/2020 20:50, Goffredo Baroncelli wrote:
> 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?

In real life situations (particularly outside a commercial datacentre)
this situation can persist for quite a while. I recently found myself
in a real-life situation where this situation was not only in existence
for weeks but was, at some times, getting worse (I was getting further
away from my target configuration, not closer).

In this case, the original trigger was a disk in a well over 10TB
filesystem beginning to go bad. My strategy for handling that was to
replace the failing disk asap, and then rearrange the disk usage on the
system later. In order to handle the immediate emergency, I made use of
existing free space in LVM volume groups to replace the failing disk,
but that meant I had some user data and backups on the same physical
disk for a while (although I have plenty of other backups available I
like to keep my first-tier backups on separate local disks).

So, once the immediate crisis was over, I needed to move disks around
between the filesystems. It was weeks before I had managed to do
sufficient disk adds, removes and replaces to have all the filesystems
back to having data and backups on separate disks and all the data and
metadata in the profiles I wanted. Just doing a replace for one disk
took many days for the system to physically copy the data from one disk
to the other.

As this system was still in heavy use, this was made worse by btrfs
deciding to store data in profiles I did not want (at that point in the
manipulation) and forcing me to rebalance the data that had been written
during the last disk change before I could start on the next one.

Bottom line: although not the top priority in btrfs development, a
simple way to control the profile to be used for new data and metadata
allocations would have real benefit to overstretched sysadmins.