On Feb 21, 2014, at 1:54 AM, Richard Hughes <hughsient@xxxxxxxxx> wrote: > On 21 February 2014 05:46, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> LVM Thin Provisioning > > Now the kernel doesn't explode when thinp runs out of physical space > I'm happier considering this. Yeah. I'm personally not as interested in LVM thinp for the general use case because it's overly complicated with layers and obscure commands. You have to understand LVM pretty well to grok LVM thinp. That's not the case with Btrfs. But I think both should be considered in parity when it comes to designing a snapshot/rollback strategy that works well regardless of what's backing it. > btrfs has been stable for me, but suffers > hugely when trying to use a VM on top of it without chattr +C. This is expected. It's an open question if apps like virt-manager, Boxes, etc. should set +C xattr on containing directories when on Btrfs; or if the currently active work on its autodefrag option will obviate +C, and when it will become a default mount option. > I was intending to use snapper, but the real problems lie as we also > want to snapshot /boot, might not want LVM/btrfs for > performance/stability reasons, and that we actually want some things > to be excluded from the snapshot, e.g. the systemd journal. I think all of those have fairly straightforward workarounds already, e.g. create a log subvolume (or LV) and mount it at /var/log and then never snapshot or roll it back. Another case is /home. It means rollbacks conditional, and there isn't such a thing as one kind of rollback. Rolling back /home doesn't imply rolling back the system. Rolling back the system doesn't mean rolling back /home. Those two seem very basic to distinguish between. There may be others. And there may be better ways to achieve them instead of fs level rollback. Btrfs does provide file level snapshots so it can be rather granular if there's demand for it. /boot concern has possibly two work arounds: retain more kernels, and don't have too many (or too old) system level snapshots. Chris Murphy -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
