libblockdev icon indicating copy to clipboard operation
libblockdev copied to clipboard

btrfs plugin missing a check for minimum file system size for shrink

Open cmurf opened this issue 4 years ago • 6 comments

GNOME Disks lacks resize support for Btrfs. But libblockdev has it. https://github.com/storaged-project/libblockdev/blob/master/src/plugins/btrfs.c#L876-L902

But it's missing a check for the minimum possible shrink size: 'btrfs inspect-internal min-dev-size' And before it can, this btrfs-progs bug needs fixed. https://github.com/kdave/btrfs-progs/issues/271

Also, maybe there should be a better interface for libblockdev to use?

Also, in the multiple device case, if a device is not specified for resize, devid 1 is assumed. That suggests (a) fully supporting multiple device resizes; (b) a way to inhibit/block resize if it's a multiple device btrfs. How to know if it's multiple device? #244 probably needs a solution before knowing whether the device can be mounted as well as how many devices.

cmurf avatar Jul 12 '20 20:07 cmurf

GNOME Disks lacks resize support for Btrfs. But libblockdev has it. https://github.com/storaged-project/libblockdev/blob/master/src/plugins/btrfs.c#L876-L902

Even better, we have the Btrfs resize support in UDisks too -- http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Filesystem.BTRFS.html#gdbus-method-org-freedesktop-UDisks2-Filesystem-BTRFS.Resize (but it uses libblockdev so it has the same problems).

But it's missing a check for the minimum possible shrink size: 'btrfs inspect-internal min-dev-size' And before it can, this btrfs-progs bug needs fixed. kdave/btrfs-progs#271

We should probably add the min dev size to the Btrfs info.

Also, in the multiple device case, if a device is not specified for resize, devid 1 is assumed. That suggests (a) fully supporting multiple device resizes; (b) a way to inhibit/block resize if it's a multiple device btrfs. How to know if it's multiple device? #244 probably needs a solution before knowing whether the device can be mounted as well as how many devices.

Yes, multiple devices won't be easy. I'm open to suggestions, I've never really tried to resize a raid/complex btrfs volume.

vojtechtrefny avatar Jul 14 '20 15:07 vojtechtrefny

Yes, multiple devices won't be easy. I'm open to suggestions, I've never really tried to resize a raid/complex btrfs volume.

One approach might be listing common use cases, and seeing if there are particular points of user confusion that a GUI could help avoid or resolve. Btrfs single device shrink and grow are straightforward. There is a rather old GNOME Disks issue, about Btrfs support generally, but there is recent activity including resize.

One angle might be to constrain multiple device support when the data profile is 'single', and metadata profile is 'single' or 'dup' or 'raid1'. The data 'single' and metadata 'raid1' case will be the mkfs.btrfs default, and will be the default outcome in Anaconda if the user chooses 2+ devices for Guided/Automatic partitioning path. What might users want to do with this post-install?

  • shrink either or both devices, by arbitrary amounts
  • remove or add devices
  • replace devices

Some of that is scope creep beyond just literal resize. But Btrfs makes it pretty easy to support it, if desired. The biggest leap is if the user wants to go from multiple devices, to single. Due to 'raid1' metadata, it's not possible in one step, Btrfs complains:

# btrfs device remove /dev/loop2 /media                              │
ERROR: error removing device '/dev/loop2': unable to go below two devices on raid1    │

But it's possible to first convert the metadata to 'single' (SSD) or 'dup' (HDD). And then device removal is permitted, which implies shrink. All of this is done while the fs is mounted and is handled by kernel code. The migration of data from the device being removed to the remaining device is functionally like LVM's pvmove. At the end, it wipes magic on the removed devices. It doesn't change MBR/GPT partitioning.

What I don't know much about is what kind of interface is preferred in libblockdev? Using ioctls directly, like the btrfs user space tools do? Or is it better to enhance libbtrfs so libblockdev has an API? I'm not qualified to assess the current state of libbtrfs but if that's where certain things belong, I'll help make the case to get that work done.

cmurf avatar Jul 17 '20 16:07 cmurf