On Tue, 2017-04-18 at 17:19 +0000, Nir Soffer wrote: On Tue, Apr 18, 2017 at 12:23 AM Pavel Gashev <[email protected]<mailto:[email protected]>> wrote:
Nir, A process can chdir into mount point and then lazy umount it. Filesystem remains mounted while the process exists and current directory is on mounted filesystem. # struncate -s 1g masterfs.img # mkfs.ext4 masterfs.img # mkdir masterfs # mount -o loop masterfs.img masterfs # cd masterfs # umount -l . # touch file # ls # cd .. # ls masterfs Interesting idea! The only issue I see if not having a way to tell if the file system was actually unmounted. Does process termination guarantee that the file system was unmounted? You can double check that by deactivating underlying LV. It should not be busy. As I understand it unmounts FS as soon as all inodes are closed. Since killing of process is closing all open inodes, you can be sure that file system is unmounted if there are no other processes. Of course this is a place for race conditions. For example, unmounting can be stuck some time if underlying storage is unresponsive. Multipath should drop all IOs with EIO. VDSM has to wait enough time after acquiring the lock before mounting masterfs. Do you know if the behaviour is documented somewhere? umount(8): -l, --lazy Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. (Requires kernel 2.4.11 or later.)
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
