Patrick O'Callaghan wrote:
By design, the default action of umount is to fail if there are any open files on the filesystem. I am not sure what potential race condition you are talking about - I would think that proper unmount code would first make sure the file system in not in use, then block opening of files on the file system, write any dirty buffers, and then unmount the file system.You've stopped using the filesystem, you sync to make sure everything's hunky dory, then you unmount. If you can't be sure that activity has stopped (i.e. there are no open files or current directories on the fs) you have to hope that unmount will fail and let you know, but there is a potential race condition if you're not careful. The only way to avoid the race would be if 'unmount' included a 'sync' within the kernel, but the docs don't say that. I imagine the reason it's that way is that unmount can take an indeterminate amount of time, especially for remotely mounted filesystems. Just speculating of course. poc
From the umount man page:Note that a file system cannot be unmounted when it is ‘busy’ - for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use. The offending process could even be umount itself - it opens libc, and libc in its turn may open for example locale files. A lazy unmount avoids this problem.
Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
