23

I would like to be able to merge changes from the upper filesystem of an overlay mount to a lower filesystem.

I am interested both online (i.e. merge while the overlay is mounted) and offline (unmount the overlay and then merge) solutions.

I have found a couple of offline solutions, which I have added as answers.

Does anyone know of any online solutions? It would be good to have a "commit" type command you could run to merge down the layers while the overlay is still mounted.

Something like this has been asked in the following questions with no answer:

Comments in these posts suggest variously mergerfs and bcache, both of which solve specific use cases but not the generic filesytem-agnostic use case that overlays provide.

My goal is to have a safe filesystem sandbox with snapshots that can be used with any Linux application over any (where practical) underlying filesystem, allowing you to roll back changes or manually commit them when you are ready.

I have a suspicion that modern mainline Linux has all the necessary features to do this built-in, thanks to all the sandboxing/virtualization innovations of the last few years, if only I knew how to use them.

ejm
  • 601
  • 1
    overlayfs snapshots are coming to a kernel near you – Ahmed Masud Oct 08 '17 at 17:03
  • I am not that familiar with the intricacies of the kernel and filesystems, but out of curiosity, what would be the problem with something along the lines of rsync -a --delete merged/ lower/ to replicate what is seen inside the overlayfs mountpoint to the lower directory ? Obviously it would be an offline solution, as it's not atomic. But it seems easier than rdiffdir, so I might be missing something. – etnbrd Jul 19 '18 at 18:07
  • @AhmedMasud, as I understand, snapshots could freeze the state of the overlayfs. So I guess you mentioned it to resolve the atomic part of an online solution. But I fail to see past this, and how it could be possible to replicate the snapshot onto the lower dir. Did you have an idea about this ? Or maybe I am completely missing your point (I am not that familiar with these kernel features :p ) – etnbrd Jul 19 '18 at 18:14
  • 1
    Did you ever find something more? I'm on a Raspberry Pi which gets detonated on improper shutdown. Want to use overlayfs to protect it and sync down to lower judiciously – Malachi Dec 22 '19 at 09:26
  • @ejm Have you found a satisfactory solution? – Max Beikirch Jul 03 '21 at 20:51

5 Answers5

6

I have found the overlayfs-tools project which implements a useful set of tools (diff, merge and vacuum). It requires the overlay to be unmounted so is an offline-only solution.

It is a good proof-of-concept but I wouldn't rely on it in its current state as it has only a single maintainer and no activity for several years.

ejm
  • 601
6

An attempt at an online solution, but its not quite there.

The setup (in e.g. /tmp directory, as root):

LOWER=$HOME
mkdir u1 w1 o1 O
mount -t overlay overlay -o lowerdir=$LOWER,upperdir=u1,workdir=w1 o1
mount --bind o1 O

Then you can work in O directory, which is an overlay over $LOWER. When you want to do the snapshot:

mkdir u2 w2 o2
mount -t overlay overlay -o lowerdir=o1,upperdir=u2,workdir=w2 o2

(Note that nested overlays like this won't work on older kernels).

But then I want some way to atomically change the bind mount at O to point to o2 instead of o1. I don't know how to do this other than:

umount O
mount --bind o2 O

(Not atomic; there is a window where O is unmounted).

Ideally, running processes could continue to run without knowing that the underlying filesystem of O had changed from o1 to o2. I don't know if this is possible, or whether changing the underlying filesystem of O like this will disrupt open applications too much. I need to investigate further.

Then, once O has been redirected to o2, we can remount o1 read-only as a precaution, then perform an offline merge using for example rdiffdir or overlayfs-tools.

Finally, we would want some way to atomically remount o2 as lowerdir=$HOME,upperdir=u2,workdir=w2 so that o1, u1 and w1 (all now empty dirs) could be removed. Again, I don't know if this is possible.

Otherwise, we can achieve snapshots by just nesting overlays deeper and deeper and leaving the overlay and upper dirs for each mounted without attempting to merge or cleanup. But there is probably a limit to the number of nested overlays that can be mounted. And at some point, we still need to merge the layers downwards if we want to persist changes.

fra-san
  • 10,205
  • 2
  • 22
  • 43
ejm
  • 601
3

Another offline solution I've come up with is using rdiffdir to create a patch with the overlay mounted, then unmount and apply it. This solution requires the intermediate step of storing the patch somewhere in the meantime (either on disk or in a ramdisk/tmpfs).

terdon
  • 242,166
ejm
  • 601
1

I use it in https://github.com/StuartIanNaylor/zram-config has quite a few installs zram-config merges down on shutdown and seems to work for quite a number of users.

I wish the OverlayFS team would produce some official tools. Aufs has tools but isn't included in many kernels and it seems on oversight for overlayfs not to have snapshot to lower merge down tools as it will greatly enhance use scenario.

0

==Explanation==

I would use Btrfs snapshots to merge the upper and lower directories. A Btrfs subvolume works almost exactly like a directory, but we snapshot (clone) a subvolume and it takes no extra disk space. Then rsync the contents of the Overlayfs to the snapshot, and it will only use as much disk space as doubling the upper directory. After rsync is complete, then the original lower and upper directories can be discarded, and replaced by the new snapshot and a new (empty) upper directory.

==Steps==

  1. Create a Btrfs subvolume as the lower directory (after some days or weeks, when you're ready to merge, then go to step 2)
  2. Take a (writable) snapshot of the lower directory.
  3. While the Overlayfs is mounted, use rsync to synchronize all changes from the Overlayfs to the snapshot.
  4. Unmount the Overlayfs.
  5. Delete the lower directory
  6. Replace the previous lowerdir with the new snapshot.
  7. Delete the upper directory.
  8. Recreate a new (empty) upper directory.
  9. Remount the Overlayfs filesystem.

==Steps as terminal commands (untested!)==

1# btrfs subvolume create lowerdir
2# btrfs subvolume snapshot lowerdir lowerdir_new
3# rsync --delete -a overlayfs lowerdir_new
4# umount overlayfs
5# btrfs subvolume delete lowerdir
6# mv lowerdir_new lowerdir
7# rm -rf upperdir
8# mkdir upperdir
9# mount -o lowerdir

A Btrfs snapshot IS a new subvolume, so this process can be repeated unlimited times.

Rucent88
  • 1,880
  • 4
  • 24
  • 37