Hi David, thanks for the reply.
Yep, we're planning to add support to DeviceKit-disks for
exposing the (privileged) operations that btrfs may expose
(locked down by polkit, etc etc). There are also plans to expose
these operations in the UI in Palimpsest and/or Nautilus. I don't
think snapshots is going to have any Palimpsest UI (it belongs in
Nautilus I think) but the multi-disk stuff definitely will.
I don't think it makes sense for the filesystem-level snapshot
operations I describe in the feature proposal to be in Nautilus:
https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs
The proposal is about system-administrator decisions on what your root
directory on btrfs will look like at next boot; they should only be
performed by someone deep into "I am modifying the mount behavior of
my fs" mode.
(It does make sense for a Time Slider port to Btrfs, working with
file-level operations on snapshots, to live inside Nautilus.
That's not part of this proposal, but would be very useful work.)
Given the above, do you think you'd be okay with having:
Filesystem snapshot that will be active on next boot: <drop-down>
and
Create new whole-filesystem snapshot now: <label> <apply>
in a Btrfs-specific section in Palimpsest? That's all that's needed
for the UI component of this feature.
As always, DKD and Palimpsest is supposed to be complementary to
the command-line tools. So all this is only relevant for creating
nice UIs for managing btrfs.
Yup, that's the case.
(Oh, and if it turns out that creating/destroying btrfs snaphots
isn't a privileged operation (I can't remember at this point) it
would probably make sense for Nautilus to just use the btrfs
tools directly instead of going through a system daemon. There's
just no need to overcomplicate things.)
Creating a new snapshot is unprivileged, but mounting an old one
(which nautilus would need to do in order to show you the contents
of a previous snapshot, so that you can decide which files you want
to restore from it) requires a mount(8) call for each snapshot.
Thanks,
- Chris.
--
Chris Ball <cjb(a)laptop.org>
One Laptop Per Child