Replace a mounted squashfs image file
 

Is there a way to atomically replace a squashfs image file that is already mounted?

In my case, /mnt/cdrom/squashfs.img is mounted on /mnt/livecd and /usr is a symlink to /mnt/livecd/usr. So, all commands and binaries are coming /mnt/livecd, which all the daemons which are running, have their executable pages coming from /mnt/livecd.

I want to replace /mnt/cdrom/squashfs.img without killing those daemons. I can not unmount (won't even be allowed because FS is in use) because even the 'mount' program and its dependent libs can get paged out, and I can not remount after overwriting squashfs.img because between 'cp' and 'mount -o remount...', some daemon may have asked for a file block which may not even be a valid block number in the new image.

I need something like:

freeze FS
copy new_squashfs.img squashfs.img
remount /mnt/livecd
discard or rebuild all in-memory block references
unfreeze FS

Its pretty much like pulling the disk from underneath the FS. The only saving grace is that FS is read only in this case, so it should be doable.

Unmounting a filesystem while programs are using is not possible. Removing a mounted filesystem is also not possible.

Perhaps you can use ram (tmpfs, zram, ramdisk) to store/setup your commands and their libraries and then try what you want to do.

Have you checked out the man page on the umount command? Specifically, the "-l" option, which performs a 'lazy' unmount? This will detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. So the /mnt/livecd filesystem will detach and let you re-mount it to a different image...the programs that are running should still continue to run in memory, until they complete. After the unmount, you should be able to remove links to that 'mounted' file system, since it will DISmounted at that point.

I have *NEVER* attempted anything like this, though, and it's not really a good thing to do, in my opinion. Personally, I'd schedule downtime and do things cleanly.

---------- Post added 02-18-15 at 09:07 AM ----------

Wrong on both counts. Read the man pages on umount.
So then why don't you show us how??? You post things like this frequently, saying "perhaps you can do xxxx", but don't ever seem to offer any advice past that.

Maybe mount over the original image?
As I understand (and just tested), existing calls to files would continue uninteruppted. However new calls would be sent to the new mounted squash image.

The obvious flaw here is that you cannot umount the orginal mounted squash image until you umount the second one.

So while /mnt/livecd has /mnt/cdrom/squashfs.img, mount /mnt/cdrom/newsquashfs.img onto /mnt/livecd

I have not tested this in production though, so it may or may not be safe.
You're asking to pull a mounted fs from underneath while daemons are using it though, if possible I would say a clean reboot would be the better choice. (Which sometimes isn't possible)

Agreed...while this CAN be done...I'd not want to do it in production.

So how does he knows umount happened. By using a regular poll.

So you want me to be his machines system administrator. I can only give a lead or a way of process.

I don't think mounting new squashfs image over the existing mount point is an issue. That's pretty much same as doing a live yum update of a library like glibc which is used by pretty much every program on the system.

But the problem is my use case is not served well by that. I want to switch between two squashfs installs, keeping the last one handy in case an update breaks an app I use. If my original mount point gets buried underneath, I can't unmount it and make the next update point to it.

What I am thinking now is to use a symlink because symlink is smallest atomic operation that has few chances of failing.

In this install /usr is a symlink to /mnt/livecd-sym/usr instead of standard /mnt/livecd/usr

Then, I make /mnt/livecd-sym a symlink to /mnt/livecd

I mount the new squashfs to /mnt/livecd2 and point the /mnt/livecd-sym to /mnt/livecd2 if its pointing to /mnt/livecd and vice versa. /mnt/livecd (or /mnt/livecd2) can be unmounted (only lazy umount will work here) at this time. The old programs will continue to get stuff from caches and new programs will read from new squashfs image.

I tried this on a fully booted system with desktop running and things work fine. But the two squashfs images I used do not differ that much from each other. I will need to make a glibc switch to actually be sure that this will work.

No, you know unmount happens by the return status of the command. And a well-documented one at that.
Not asking you to be HIS administrator, but to STOP GIVING MISLEADING, INCORRECT, OR USELESS ADVICE. You said "Perhaps you can use ram (tmpfs, zram, ramdisk) to store/setup your commands and their libraries and then try what you want to do."

Great...since you said that, why don't you 'lead' or 'give way of process', by actually showing us examples of what you're talking about. "Perhaps" by giving an actual command, process, documentation, or SOMETHING to support what you're saying. Just telling people "perhaps you can do xxx" is useless; telling people they can't do something which is easily done is incorrect.

So...support what you said by giving us examples of how to do exactly what you stated.

I had to patch genkernel package to use create the /mnt/livecd-sym symlink and refer /mnt/livecd-sym instead of /mnt/livecd when creating symlinks for /usr, /bin, /lib64 etc.