An operation for filesystem tucking
An operation for filesystem tucking
Posted Apr 3, 2023 22:13 UTC (Mon) by stefanha (subscriber, #55072)In reply to: An operation for filesystem tucking by NYKevin
Parent article: An operation for filesystem tucking
This seems fragile to me, but then, in place updates are always tricky.
Posted Apr 4, 2023 7:38 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (2 responses)
Posted Apr 9, 2023 7:49 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
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.
Posted Apr 9, 2023 10:46 UTC (Sun)
by smurf (subscriber, #17840)
[Link]
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.
An operation for filesystem tucking
An operation for filesystem tucking
An operation for filesystem tucking