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
    https://bugzilla.gnome.org/show_bug.cgi?id=608204

 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
    udev properties

 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:

P: /devices/virtual/block/loop0
S: disk/by-uuid/b46ed8d4-3bec-4e04-bfe1-fa05def90a5d
S: disk/by-label/testb
E: ID_FS_LABEL=testb
E: ID_FS_UUID=b46ed8d4-3bec-4e04-bfe1-fa05def90a5d
E: ID_FS_UUID_SUB=8e51cade-a61f-4ea8-b029-627df8c0e47a
E: ID_FS_TYPE=btrfs

P: /devices/virtual/block/loop1
S: disk/by-uuid/b46ed8d4-3bec-4e04-bfe1-fa05def90a5d
S: disk/by-label/testb
E: ID_FS_LABEL=testb
E: ID_FS_UUID=b46ed8d4-3bec-4e04-bfe1-fa05def90a5d
E: ID_FS_UUID_SUB=084af4d5-3c6d-4e2c-9485-d4f8260f10c2
E: ID_FS_TYPE=btrfs

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.

Hi Martin,

(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 */
    }

Hi,

(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.

Hi Martin,

(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
> 0.19.

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:
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg04282.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552553

(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:

$ mount
[...]
/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
 referenced 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.

Chris,

I have btrfs running on my system partition for about two weeks now, and it does online fsck just fine. (That's on 2.6.35.1 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.

http://cgit.freedesktop.org/udisks/commit/?id=0da4c9cf59e2a977553b5473faf9aa422a1aff47
http://cgit.freedesktop.org/udisks/commit/?id=349273e5d54dee7953b0de3ec5b959cc529eb5a0

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
https://bugzilla.gnome.org/show_bug.cgi?id=746769

This is (I'm kinda guessing here) the underlying problem

[udisks] manages Btrfs multiple device volumes incorrectly, cannot umount
https://bugs.freedesktop.org/show_bug.cgi?id=87277

[gnome-control-center] > Details > Disk value is wrong
https://bugzilla.gnome.org/show_bug.cgi?id=708786

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.