udisks should know about Btrfs.
There'll be new known_file_systems struct entries to add for new features, such as "supports_snapshots".
Yup, we should know about btrfs.
Since btrfs supports multiple block devices, we need something like the LinuxLvm2PV* and LinuxMdComponent* properties for each btrfs component. And ditto for methods.
So there's a bit of design work to do - I think we should design it top-down, e.g.
1. Decide on what user experience we want - that's already filed here
2. Decide what kind of udisks D-Bus API we want - e.g.
- D-Bus properties, methods
3. Decide what udev properties we need for this
Once we got a plan hashed out, we can start implementing this bottom-up
a. probably make btrfs-progs supply an udev rule that exports the
b. teach udisks about reading these udev properties
c. implement support in Palimpsest and udisks(1)
All this sounds like a lot of work but it really isn't. Unless we run into more fundamental problems like the on-disk btrfs data structures not giving us the information we need.
Created attachment 36287 [details] [review]
basic btrfs support
I agree that we need new API to support all of btrfs' functionality.
For the simple (and probably common) case of using no RAID and only one device, it still seems nice to support the Device.FilesystemCreate() API. This patch adds support for that, including automatic tests. Want me to apply this for the time being?
(1) Let's discuss in the GNOME bug, but since btrfs has by and large the same features as MD, the interface should be consistent with that. I. e. we could have a new section in the left bar for the btrfs volumes and treat the individual component devices like RAID members (which they are really).
(3) Right now blkid/udev have enough information to be able to identify btrfs devices and group them together to volumes:
I. e. for a particular btrfs volume, the device components have the same UUID, but different sub-UUIDs.
However, what's missing is the RAID mode. You can specify it at mkfs.btrfs time, but I don't see a way how to get it back once it's created.
$ sudo btrfs-show
Label: testb uuid: b46ed8d4-3bec-4e04-bfe1-fa05def90a5d
Total devices 2 FS bytes used 28.00KB
devid 1 size 300.00MB used 124.00MB path /dev/loop0
devid 2 size 300.00MB used 104.00MB path /dev/loop1
This doesn't tell me anything more than blkid. I checked the other tools in btrfs-tools and none of them can query this either. It's certainly not an essential piece of information, but would still be nice to get. I'll do some RTFS and report back.
(In reply to comment #2)
> Created an attachment (id=36287) [details]
> basic btrfs support
> I agree that we need new API to support all of btrfs' functionality.
> For the simple (and probably common) case of using no RAID and only one device,
> it still seems nice to support the Device.FilesystemCreate() API. This patch
> adds support for that, including automatic tests. Want me to apply this for the
> time being?
Here's a slightly more correct filesystems struct. (Changes name, max length, online fsck to no, supports online resize to yes.)
"btrfs", /* id */
"Btrfs", /* name */
TRUE, /* supports_unix_owners */
TRUE, /* can_mount */
TRUE, /* can_create */
256, /* max_label_len */
FALSE, /* supports_label_rename */
FALSE, /* supports_online_label_rename*/
TRUE, /* supports_fsck */
FALSE, /* supports_online_fsck */
TRUE, /* supports_resize_enlarge */
TRUE, /* supports_online_resize_enlarge */
TRUE, /* supports_resize_shrink */
TRUE, /* supports_online_resize_shrink */
(In reply to comment #3)
> However, what's missing is the RAID mode. You can specify it at mkfs.btrfs
> time, but I don't see a way how to get it back once it's created.
"btrfs filesystem df" with btrfs-progs from Git will (counter-intuitively) tell you this.
Chris, thanks for the "btrfs filesystem df" hint and the label length/name fixes. I'm just a little confused about online fsck, https://btrfs.wiki.kernel.org/index.php/Main_Page claims it is supported, and indeed I can run fsck on a mounted btrfs just fine. That's with btrfs-tools 0.19.
(In reply to comment #6)
> Chris, thanks for the "btrfs filesystem df" hint and the label length/name
> fixes. I'm just a little confused about online fsck,
> https://btrfs.wiki.kernel.org/index.php/Main_Page claims it is supported, and
> indeed I can run fsck on a mounted btrfs just fine. That's with btrfs-tools
I'm surprised the webpage mentions it -- I think it's being cited as a feature of the design rather than something that's currently implemented.
See, for example:
(I've seen fsck segfaults that only happened on a mounted fs too.)
I've left an IRC question for the developers on whether it's supported, but I think we should assume not until we hear otherwise.
(In reply to comment #7)
> I'm surprised the webpage mentions it -- I think it's being cited as a feature
> of the design rather than something that's currently implemented.
Oh, this would make sense, given that directly underneath the list of features is:
"Currently the code is in an early implementation phase, and not all of these have yet been implemented."
Hm, then fsck.btrfs is very confusing:
/dev/loop0 on /mnt type btrfs (rw)
$ sudo fsck.btrfs /dev/loop0
found 28672 bytes used err is 0
total csum bytes: 0
total tree bytes: 28672
total fs tree bytes: 4096
btree space waste bytes: 23078
file data blocks allocated: 0
Btrfs Btrfs v0.19
When I umount /mnt, it looks exactly the same way. But oh well, I'm happy enough to disable the online fsck flag for now.
I'm still waiting for David's opinion on whether we should commit th is in the first place.
I have btrfs running on my system partition for about two weeks now, and it does online fsck just fine. (That's on 184.108.40.206 and btrfs-tools from 2010-06-01). Do you still think we should disable it?
Initial btrfs support committed. I disabled online fsck for now according to Chris' advice.
Comment on attachment 36287 [details] [review]
basic btrfs support
Marking patch as obsolete as it was committed ages ago, to clean up search lists.
What's the status of this? Does the kernel, libbtrfs, or VFS now provide udisks what it needs? And if not is now a good time to plot an agenda, maybe for Linux Plumbers Conference?
I'm starting to find some (probably unsurprising) bugs, which are more due to the lack of awareness of Btrfs, but act distinctly like bugs.
[gvfs] bogus "you can now unplug" even though volume is still mounted
This is (I'm kinda guessing here) the underlying problem
[udisks] manages Btrfs multiple device volumes incorrectly, cannot umount
[gnome-control-center] > Details > Disk value is wrong
From the first bug, I gather udisks needs to get something from either the kernel or libbtrfs or VFS, and gvfs gets what it needs from udisks. And gnome-shell and Nautilus get what they need from gvfs.
Various Btrfs developments since this bug was filed:
- openSUSE is using Btrfs, with lots of snapshotting, by default
- Btrfs sysfs improvements in kernels 3.14 and 3.16.
- VFS improvements related to btrfs
- systemd-219 is creating subvolumes for containers and uses btrfs snapshots for fast cloning
- Different subvolume layout and purpose between openSUSE and Fedora
And something probably worth incorporating (mentally) in design strategy, is the LVM thin provisioning stuff; its snapshots are completely independent filesystem volumes.