After a few years (like two?) of wandering around, I'm finally back using
ArchLinux and wonder why I ever went on searching for something better in the
first place. Feels good to be home..
Well, I installed ArchLinux a while back on my Laptop and switched yesterday to
using btrfs as my fs for everything except boot, because of everything else
being encrypted. Okay, I followed the wiki-article "Installing btrfs on root"
(https://wiki.archlinux.org/index.php/Installing_on_Btrfs_root) and everything
went just fine (it does sometimes).
So I now have a subvolume __active which represents /, one for home, one for usr
and one for var.
I then wanted to test the rollback-feature presented to me during boot and
created a snapshot of the subvolume __active. I tried using this during, but it
obviously fails, because of not having anything in /usr and /var and /home.
So, my question (yes, finally) is:
Am I missing something or is just not possible to use different subvolumes (like
__active, home, usr, var) and being able to rollback your system during boot? As
far as I know btrfs-snapshots are not recursive. So wouldn't it be better
(being-able-to-rollback-wise) to just have one subvolume so that you can really
rollback everything in case something went wrong? Or is there a way to combine
the benefits of having different subvolumes and still being able to rollback the
system?
I hope I am making any sense.. It's still before the first cup of coffee, alas.
Thank you in advance,
Christian.
07-12-2012, 02:31 AM
C Anthony Risinger
BTRFS + Rollback + Subvolumes
On Wed, Jul 11, 2012 at 3:10 AM, 1126
<mailinglists@elfsechsundzwanzig.de> wrote:
>
> So I now have a subvolume __active which represents /, one for home, one for usr
> and one for var.
[...]
> Am I missing something or is just not possible to use different subvolumes (like
> __active, home, usr, var) and being able to rollback your system during boot? As
> far as I know btrfs-snapshots are not recursive. So wouldn't it be better
> (being-able-to-rollback-wise) to just have one subvolume so that you can really
> rollback everything in case something went wrong? Or is there a way to combine
> the benefits of having different subvolumes and still being able to rollback the
> system?
nah, you're not missing anything, and are absolutely correct.
i've no idea why the page now says what it does -- it appears to have
been completely ... ehm ... butchered since myself and Eigrad/Andrew
initially wrote it, oooh about 18 months ago:
... nor am i sure why so much red and yellow was strewn about;
everything is (was?) confirmed/factual. sorry :-(
i would recommend dropping the subvols ASAP, and reviewing the
original wiki linked above.
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.
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.
--
C Anthony
07-12-2012, 02:44 AM
C Anthony Risinger
BTRFS + Rollback + Subvolumes
On Wed, Jul 11, 2012 at 9:31 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
>
> https://wiki.archlinux.org/index.php?title=Installing_on_Btrfs_root&oldid=129 890
[...]
> i would recommend dropping the subvols ASAP, and reviewing the
> original wiki linked above.
... i meant to also suggest you keep GRUB2 et al, because installing
to a partition turned out to be a massive PITA for numerous reasons.
my recommended setup is GRUB2 on GPT layout (1 bios_grub/EFI, 1 swap,
and 1 system btrfs partition), with the actual system installed to
(system)/__active and grub installed to (system)/boot (similar to the
original article).
--
C Anthony
07-12-2012, 02:45 AM
C Anthony Risinger
BTRFS + Rollback + Subvolumes
On Wed, Jul 11, 2012 at 9:44 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
> On Wed, Jul 11, 2012 at 9:31 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
>>
>> https://wiki.archlinux.org/index.php?title=Installing_on_Btrfs_root&oldid=129 890
>
> [...]
>
>> i would recommend dropping the subvols ASAP, and reviewing the
>> original wiki linked above.
>
> ... i meant to also suggest you keep GRUB2 et al, because installing
> to a partition
^^^^^^^^ er, i mean partition-less DISK!
bleh sorry for the spam, sleep-deprived ... night y'all!
--
C Anthony
07-12-2012, 05:34 AM
Gour
BTRFS + Rollback + Subvolumes
On Wed, 11 Jul 2012 21:31:59 -0500
C Anthony Risinger <anthony@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.
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.
Now, I wonder why to drop subvols (I would not many, but, at least, to
separate / & /home)?
> 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?
> 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. :-)
Sincerely,
Gour
--
Therefore, without being attached to the fruits of activities,
one should act as a matter of duty, for by working without
attachment one attains the Supreme.
On Thu, Jul 12, 2012 at 12:34 AM, Gour <gour@atmarama.net> wrote:
> On Wed, 11 Jul 2012 21:31:59 -0500
> C Anthony Risinger <anthony@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 ;-)