[U-Boot] [PATCH v2] test: ums: Add sleep before unmount directory

[Marek Vasut <marex@denx.de>]

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