> -----Original Message----- > From: linux-btrfs-owner@xxxxxxxxxxxxxxx <linux-btrfs- > owner@xxxxxxxxxxxxxxx> On Behalf Of Zygo Blaxell > Sent: Wednesday, 25 March 2020 3:10 PM > To: Graham Cobb <g.btrfs@xxxxxxxxxxx> > Cc: linux-btrfs <linux-btrfs@xxxxxxxxxxxxxxx> > 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. 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.
