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

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Wed, Mar 25, 2020 at 04:30:16AM +0000, Paul Jones wrote:
> > -----Original Message-----
> > From: linux-btrfs-owner@vger.kernel.org <linux-btrfs-
> > owner@vger.kernel.org> On Behalf Of Zygo Blaxell
> > Sent: Wednesday, 25 March 2020 3:10 PM
> > To: Graham Cobb <g.btrfs@cobb.uk.net>
> > Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
> > Subject: Re: Question: how understand the raid profile of a btrfs filesystem
> 
> > Disk removes are where the current system breaks down.  'btrfs device
> > remove' is terrible:
> > 
> > 	- can't cancel a remove except by rebooting or forcing ENOSPC
> > 
> > 	- can't resume automatically after a reboot (probably a good
> > 	thing for now, given there's no cancel)
> > 
> > 	- can't coexist with a balance, even when paused--device remove
> > 	requires the balance to be _cancelled_ first
> > 
> > 	- doesn't have any equivalent to the 'convert' filter raid
> > 	profile target in balance info
> > 
> > so if you need to remove a device while you're changing profiles, you have to
> > abort the profile change and then relocate a whole lot of data without being
> > able to specify the correct target profile.
> > 
> > The proper fix would be to reimplement 'btrfs dev remove' using pieces of
> > the balance infrastructure (it kind of is now, except where it's not), and so
> > 'device remove' can keep the 'convert=' target.  Then you don't have to lose
> > the target profile while doing removes (and fix the other problems too).
> 
> I've often thought it would be handy to be able to forcefully set the
> disk size or free space to zero, like how it is reported by 'btrfs
> fi sh' during a remove operation. That way a balance operation can be
> used for various things like profile changes or multiple disk removals
> (like replacing 4x1T drives with 1x4T drive) without unintentionally
> writing a bunch of data to a disk you don't want to write to anymore.

I forgot "can only remove one disk at a time" in the list above.  We can
add multiple disks at once (well, add one at a time, then use balance to
do all the relocation at once), but the opposite operation isn't possible.

That is an elegant way to set up balances to do a device delete/shrink,
too.

> It would also allow for a more gradual removal for disks that need
> replacing but not as an emergency, as data will gradually migrate
> itself to other discs as it is COWed.
> 
> Paul.