An operation for filesystem tucking

Posted Mar 31, 2023 20:59 UTC (Fri) by epa (subscriber, #39769)
In reply to: An operation for filesystem tucking by Karellen
Parent article: An operation for filesystem tucking

I guess not quite, if the old overlay provided a file which is not present in the new overlay.

An operation for filesystem tucking

Posted Mar 31, 2023 21:14 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

The new overlay could contain a whiteout, if necessary. AFAICT, the real problem is that "lazy" umount(2) exists, but "lazy" mount(2) does not exist.

An operation for filesystem tucking

Posted Apr 1, 2023 6:41 UTC (Sat) by epa (subscriber, #39769) [Link]

What if the old overlay contained a file for /etc/aliases but the new overlay does not because you decided, after all, not to override /etc/aliases but stay with the base system version.

An operation for filesystem tucking

Posted Apr 1, 2023 10:49 UTC (Sat) by Karellen (subscriber, #67644) [Link] (7 responses)

On the other hand, if the new overlay provides a file not in the old overlay, in the tuck scenario it could "peek through" before the old overlay is removed.

An operation for filesystem tucking

Posted Apr 1, 2023 20:03 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (6 responses)

IMHO this is less likely to cause problems, because it wouldn't be seen (by the processes inside the container) as an existing file getting abruptly replaced or deleted. While it is certainly possible for software to enumerate the contents of a directory and (maybe) get upset when a new file shows up unexpectedly, in practice this usually only happens at startup or on an explicit signal such as SIGHUP or SIGUSR1/2 (at least for server-like things that you would put in a container in the first place - obviously something such as GNOME is monitoring ~/Desktop all the time so that it can draw icons etc., but running GNOME in a container is probably not the target use case here).

An operation for filesystem tucking

Posted Apr 3, 2023 12:57 UTC (Mon) by mgedmin (subscriber, #34497) [Link] (1 responses)

The file in the new overlay might be overriding an existing file in the base overlay that was not being overridden by the old overlay.

An operation for filesystem tucking

Posted Apr 3, 2023 17:49 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

I think the simplest way to handle that is to make it userspace's problem: If you want to tuck a new overlay that overrides files in the base overlay, you first tuck a copy of the old overlay that also contains all of the files you are going to override. Any reasonable container system should be keeping track of what files are supposed to exist in each layer, and so it should be able to detect situations like this.

An operation for filesystem tucking

Posted Apr 3, 2023 22:13 UTC (Mon) by stefanha (subscriber, #55072) [Link] (3 responses)

It's still not atomic. A new file dropped into a .d directory can easily cause problems since the old mount is still in place with the majority of the set of files.

This seems fragile to me, but then, in place updates are always tricky.

An operation for filesystem tucking

Posted Apr 4, 2023 7:38 UTC (Tue) by smurf (subscriber, #17840) [Link] (2 responses)

Of course it's still fragile, but it's less fragile than a mount-on-top with some way to unmount the lower-layered file system later.

An operation for filesystem tucking

Posted Apr 9, 2023 7:49 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

To be fair, the classic (pre-container) way to do this is to flip a symlink, and that really is perfectly atomic.

One wonders why userspace container systems don't just put a symlink inside of the filesystem image. You could have, for example, two mount points A and B, and a symlink to whichever mount point is currently in use. When you want to upgrade to a new version, you mount it on the other mount point, and then flip the symlink. Perhaps the container software doesn't want to dictate the use of such symlinks? But that seems like a rather... insubstantial reason to make this the kernel's problem, IMHO.

An operation for filesystem tucking

Posted Apr 9, 2023 10:46 UTC (Sun) by smurf (subscriber, #17840) [Link]

If you flip that symlink while a program is starting up it'll get some libraries from A and others from B, which may cause it to crash. So in that sense it's definitely not atomic. The same problem applies to a mount-on-top operation.

On the other hand if you have a tuck-mount you can do an atomic unmount afterwards, but only if there's no current user. That guarantees that you don't run into inconsistent libraries et al. even when you can't control exactly when a program (re)starts.