[arch-general] BTRFS + Rollback + Subvolumes

[C Anthony Risinger]

On Thu, Jul 12, 2012 at 12:34 AM, Gour <gour at atmarama.net> wrote:
> On Wed, 11 Jul 2012 21:31:59 -0500
> C Anthony Risinger <anthony at xtfx.me> wrote:
>
>> i would recommend dropping the subvols ASAP, and reviewing the
>> original wiki linked above.
>
> Hmm...at the moment I use RAID-1 - 1 RAID partition for /boot
> (ext2), another for the swap and rest for the / & /home (ext4) along
> with LVM2.

why not ext4 thru-and-thru? if you REALLY don't what the journal/etc,
you can disable.  ext2 is deadzilla :-)

otherwise i have near identical setup, on my local server at least,
MDRAID -> LVM2 -> (blah), sans the separation of / and /home ... never
seen much point to it beyond needless complexity.

not a criticism by any means, just unrestrained blurbing on my part :-)

> Prospect of moving to btrfs is that we believe it would be possible to
> reduce one layer and have similar setup to the one on FreeBSD with ZFS.

i don't actually have experience on those platforms directly, but yes,
i certainly agree with the use case of slicing out layers.  the plan
ATM is to expect that a single btrfs FS manages /* and /boot, because
they are all critical for proper rollbacks.

> Now, I wonder why to drop subvols (I would not many, but, at least, to
> separate / & /home)?

well, my recomendation was to drop for the time being at least,
because the hook will not manually perform a recursive snapshot, and
btrfs doesn't currently support it, nor am i aware if it ever will.
to support, i'd need to snap /, lookup ids for all nested subvols, and
manually snap them all into place.  this is not only racy (even if
done with C, IIUC) because a subvol could be moved/dropped/etc, but
also opens a considerable gap of inconsistency (from first snap to end
of last); the unified "snapshot" as a whole would not truly reflect
the FS's state at the moment it was requested ... a single snapshot
does not have this issue.  now, one could possibly use fsfreeze to
sync() and hang apps while you do all this ... not sure, and feels
brittle.

if btrfs does not implement stable/consistent recursive snaps itself,
i'm not much inclined to handle myself, likely excluding rollback
support on partitioned hierarchies (except /boot) -- ungood, but not
detrimental.

nothing is solid though -- if good arguments lead to good solutions,
or some reasonably consistent alternative, things change.

>> alas, i've heard -- and "seemingly" confirmed -- inklings that GRUB2
>> now supports booting from a btrfs subvol -- the magic feature required
>> to perform kernel-level rollbacks! yay! as i have long since used
>> GRUB2 on all my machines and am somewhat familiar with scripting it, i
>> expect to make some extensive updates soon-ish-ly.
>
> What about syslinux which we use at the moment?

well, HPA has been on the btrfs list recently working toward improves
syslinux support, and i'm sure something will materialize in good
time.  until them though, i just syslinux would continue to limp along
without kernel rollback (ie. no change)

>> i'm not sure how relevant/beneficial this discussion can be for
>> everyone else here (though in general, the use-case itself is
>> certainly worthy of discussion) -- should you have pointed/specific
>> questions/problems feel free to ask in the AUR comments.
>
> I believe it is and that is expected that many Arch users are not
> interested for 'automatic partitioning' offered by Ubuntu installer. :-)

pfft, GRUB2 works well and allows for a cleaner impl than syslinux
can. i'd make use of GRUB2's scripting support to dynamically
enumerate available snapshots at boot-time, and probably not much more
than that. IIRC, syslinux can't do anything too interesting ... i'd
have to generate includes or something prior to shutdown.

not sure what Ubuntu does or how it relates though ... i personally
just use GRUB2 -- after several years under syslinux -- simply because
i like it and believe it's superior.  however, one of the upcoming
features after kern support is auto-snapping on every boot (or some
list of schemes) during initramfs (prior to mount /) ... ie,  quickly
"saving" the system's state then stepping aside, so you can
proceed-to-borking ;-)

-- 

C Anthony