
On Friday, November 07, 2014 at 05:52:27 PM, Lukasz Majewski wrote:
Hi Marek,
On Friday, November 07, 2014 at 02:05:55 PM, Lukasz Majewski wrote:
This change helps to run script on machines with quite long uptime. Without this the following error emerges:
File: ./dat_14M.img umount: /mnt/tmp-ums-test: device is busy.
(In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))
TX: md5sum:083d3d22b542d3ecba61b12d17e03f9f mount: /dev/sdd6 already mounted or /mnt/tmp-ums-test busy mount: according to mtab, /dev/sdd6 is already mounted on /mnt/tmp-ums-test
Signed-off-by: Lukasz Majewski l.majewski@samsung.com
Why exactly does mount not block until it can unmount the device anyway ?
Has mount or umount expose any blocking behavior?
I would expect umount to be blocking by default in the first place. ie. umount /mnt/foo should wait until all data are synced on device under /mnt/foo and only then it should be unmounted.
Can you check (with strace or something) what exact return value will the umount() syscall return when it does NOT unmount the mountpoint and returns to the shell ? Is it EBUSY ?
As fair as I remember you cannot umount directory when any process holds reference to it.
Here it looks like process which copy data queues data for writing and exit from cp.
Presumably, when we call umount there is still some pending data for write.
Hence the error.
In case there are data which are not yet sync'd to the device, the umount() syscall should block until those data are written and return only after that. Why would it return -EBUSY ... hmmmmm ...
Maybe there is a switch for mount/umount/cp which can correct such behavior?
That should be the default ...
Best regards, Marek Vasut