[systemd-devel] Merging journal logs from btrfs snapshots

[Chris Murphy]

On Jan 16, 2014, at 3:44 PM, Kai Krakow <hurikhan77 at gmail.com> wrote:

> Chris Murphy <lists at colorremedies.com> schrieb:
> 
>> 
>> On Jan 16, 2014, at 2:48 PM, Mirco Tischler <mircotischler at gmx.net> wrote:
>>> 
>>> Afair, you don't need to mount subvolumes.
>>> 
>>> 
>> I do in this case in order to make sure there's an fstab in subsequent
>> snapshots, that mounts the /var/log/journal subvolume. Otherwise, the
>> booted snapshot will end up with a new /var/log/journal and all new
>> journal entries which is not what I want.
> 
> To fix this, you may want to boot into recovery, then snapshot your current 
> rootfs. Next, snapshot your var/log/journal into [subvol0]/var-log-journal, 
> which makes that a subvolume, rename var/log/journal into a backup location, 
> recreate var/log/journal as empty directory, add the fstab entry, then take 
> a new snapshot of your rootfs.
> 
> This way you migrate to the new scheme while maintaining rolling back to the 
> old behavior. And it's easy to refix after rolling back to the old behavior 
> by just repeating the step "move journal", "create empty", "add fstab" and 
> it'll pickup your existing journal after booting back into normal mode.
> 
> After a grace period you won't need your old rootfs snapshots any longer and 
> everything is good.
> 
> It won't be that trivial if you'd made the var-log-journal within your 
> rootfs namespace (because after rolling back your subvolume is a subvolume 
> of a snapshot you'd rather delete, read: it's a sub-sub-volume).

I tend to keep the original boot, root, home subvolumes as primary. So I think it's a bit weird having <FS_TREE>/root/var/log/journal as a subvolume that is then mounted on top of itself most of the time - as that's the way it would be in order for the fstab of subsequent root snapshots to mount the journal subvolume. Otherwise I'd have to change the fstab for each snapshot = annoying. So I think I'd put the journal subvolume in top level 5, or maybe in some other tree for persistent subvolumes to mount.

Another limitation with fstab in a snapshot is that it has the wrong entries for the snapshot, those entries are only valid for the original subvolumes. So a snapshot of root subvolume called root.snap1, contains an /etc/fstab that calls for mounting subvol=root, rather than subvol=root.snap1. Making snapshots bootable poses some logistical challenges for legacy fstab, and also how to get them displayed in grub - some of the grub aspects have been discussed for several months on grub-devel at .

Also, there's an argument to be made that a legitimate snapshot should initially be read-only. Upon rollback a rw snapshot would be created from the ro snapshot.


Chris Murphy