btrfs subvolume handling
It might be desirable for gvfs to provide support for Btrfs subvolumes and subvolume snapshots. Whether subvolume/snapshot creation or deletion should be exposed in Nautilus or open/save dialogs, is up to UI/UX designers. This issue could explore what might be needed from udisks2 or libbtrfs if they don't already exist; and other high level issues.
Background:
A subvolume currently manifests in Nautilus and CLI as directories. In reality it's a dedicated files btree, with its own pool of inodes. The stat
command will report it with a unique device ID. Subvolumes always have an inode number of 256. A subvolume snapshot is a subvolume that's prefilled with the contents of the source subvolume as they exist at the moment the snapshot is taken. They can be read write (default) or read-only.
Layouts:
Fedora's installer, Anaconda, initially creates a "flat" layout with root
and home
subvolumes at the top-level of the file system, and via fstab are mounted at /
and /home
respectively, e.g.
UUID=11111111-2222-3333-4444-555555555555 / btrfs subvol=root 0 0
UUID=11111111-2222-3333-4444-555555555555 /boot btrfs subvol=boot 0 0
This top-level, showing the two subvolumes, is not exposed to the user.
If a user were to create a subvolume within ~/
this would be a "nested" layout. It manifests as a directory. It's possible to 'rm -rf' the subvolume just like a directory, with the same unlinkat() cost per item. It's faster to btrfs subvolume delete
because this removes its files btree root node, there is no traversal of the individual files including no permission or ownership checking. Cleanup of no longer used extents is handled by background cleaner kernel thread.
Btrfs wiki>SysadminGuide>Layout
Split out from #519