[ovirt-users] storage redundancy in Ovirt

Pavel Gashev Pax at acronis.com
Tue Apr 18 18:34:59 UTC 2017


On Tue, 2017-04-18 at 17:19 +0000, Nir Soffer wrote:
On Tue, Apr 18, 2017 at 12:23 AM Pavel Gashev <Pax at acronis.com<mailto:Pax at acronis.com>> 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.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170418/86b439cc/attachment-0001.html>


More information about the Users mailing list