On Thu, Jul 12, 2012 at 12:34 AM, Gour <gour@xxxxxxxxxxxx> wrote: > On Wed, 11 Jul 2012 21:31:59 -0500 > C Anthony Risinger <anthony@xxxxxxx> 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
