On Wed, Mar 25, 2020 at 04:30:16AM +0000, Paul Jones wrote: > > -----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. 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.
