btrfs Enhancements

[dcrdev]

Currently cockpit treats disks that are members of a btrfs array as individual disks and there is no support for common btrfs tasks such as scrubbing, snapshots adding/removing members etc...

All of the above is already implemented for mdadm - can this be implemented for btrfs? Ideally any btrfs raid should also appear in the raid devices box on the storage tab.

[Centril]

This addition would be neat!

[thunderstorm99]

I would also very much welcome this coming to fruition

[DidierLmn]

Would love to see this implemented if someone finds the time.

[Conan-Kudo]

Long-time Cockpit user on Fedora with Btrfs and would love to see this functionality, too!

[mvollmer]

Could you guys get together and produce some concrete proposals? UI mockups, what commands the buttons should run, etc. We don't have any btrfs users in the Cockpit team, I am afraid.

[Conan-Kudo]

@mvollmer I can certainly try to write up something about how I would expect to be able to manage Btrfs. It's a shame no one on the team uses Btrfs, though. It's a nice filesystem. 🥇

[martinpitt]

I actually do use btrfs on my laptop (happy user for many years), but not across multiple disks. I'm using it for subvolumes mostly, which are so much better than partitions or even LVM LVs.

[mvollmer]

I actually do use btrfs on my laptop (happy user for many years), but not across multiple disks. I'm using it for subvolumes mostly, which are so much better than partitions or even LVM LVs.

Oh, cool, that makes me want to try this also.

[viktorstrate]

Rockstor is an operatingsystem for NAS based on CentOS, it uses btrfs.
It also has a web ui, from where the btrfs disks can be managed.
Maybe we could take some inspiration from the way they have done it?

See their documentation for managing pools
http://rockstor.com/docs/pools-btrfs.html

[cmurf]

Subvolumes and Snapshots
I know that libbtrfsutil provides a way to support subvolume operations, enumerate, create, delete, snapshotting, and also has python3 bindings.
https://github.com/kdave/btrfs-progs/tree/master/libbtrfsutil

But I don't see any scrub or device management stuff in there. I do see subvolume operations as well as device add and remove in
https://github.com/storaged-project/libblockdev/blob/master/src/plugins/btrfs.h

Scrubbing
It might be that either libbtrfsutil and/or storaged needs some extension. But you could also just leverage a systemd service and timer units, which themselves just execute user space commands, and Cockpit could just have an enable/disable timer toggle.
Examples of this:
https://aur.archlinux.org/packages/btrfs-progs-git/
https://git.archlinux.org/svntogit/packages.git/plain/trunk/btrfs-scrub@.service?h=packages/btrfs-progs
https://git.archlinux.org/svntogit/packages.git/plain/trunk/btrfs-scrub@.timer?h=packages/btrfs-progs

A more sophisticated UI might allow changing scrub interval, manual start and stop, selection of specific file systems, progress and statistics, or even cancel/resume based on a schedule or load threshold+duration. It's not obvious but btrfs scrub cancel leaves intact a tracking file for what has been completed and btrfs scrub resume will scrub from that point. The scrub IO priority class is idle so, in theory any other request is promoted above scrub.

If there is a way to detect unclean shutdown (powerfail or crash) it'd be cool if Cockpit can present a message to the user: Unclean shutdown? Perform file system scrub (if supported)? This can apply to md, LVM, Btrfs, ZFS, XFS, and (eventually) Stratis. As much as possible I'd leverage or modify existing UI to match use cases regardless of the backend storage.

Device add and remove
Multiple device handling support would also be super cool, even in the single device about to fail and needs live replacement use case. I'm not seeing anything in libbtrfsutil about it, or python bindings, but I do see device add/remove in libblockdev. Basic support is pretty simple, choose device and volume, and click go. The add command does all the work of sanity testing the target device, formatting it, and resizing the volume; for delete it's the same, and migrates block groups live in the background similar to pvmove, and when it completes, wipes the Btrfs signature from the removed device. A possible option is supporting the newer replace subcommand which is a simpler and faster way of swapping a device with a same sized or larger replacement.

Advanced device management to handle different replication strategies? The redundancy doesn't change just by adding a device, and the balancing of data across devices is also not altered. Such handling probably requires a few extra conversations, as it's not exactly obvious what to do, because the user expectations after adding a device aren't obvious. Did they intend to make the pool bigger? Or add redundancy?

Resize
Btrfs supports live grow and shrink, there's a specifc ioctl for it, all handled by the kernel. There is no locality optimization in the Btrfs allocator, so there's no downside to multiple resizes. If anything, any compaction of block groups resulting from shrink will make the file system a bit more efficient.