rmdir failed because of "Device or resource busy" [closed]

Question

there are a lot of similar problem like "Device or resource busy". But I think my problem is different with them.

I use mount --bind to bind a directory

mount --bind /tmp/origin /tmp/mount

and then could umount successfully

umount /tmp/mount

And then if I call rm at once

rm -rf /tmp/mount

I could get a error Device or resource busy. If I wait 2~3 seconds, and then call rm, it could success.

So this behaviour is very strange here. I try use

lsof +D /tmp/mount

could not see anything.

I also use fuser -vm /tmp/mount, could not see any process hold this folder.

I compare the /proc/mounts before umount /tmp/mount and after umount /tmp/mount. /tmp/mount has already removed.

I compare the stat /proc/mounts before umount /tmp/mount and after umount /tmp/mount. The inode also different, this means /tmp/mount has already removed complete.

Even I call sync && echo 2 > /proc/sys/vm/drop_caches and try to drop file caches, it still not work.

I try this in both Ubuntu 14.04 and CentOS 6.6. They have same results.

Answer 1

In my experience, the following operations are asynchronous on Linux:

• Closing file. Immediately after close() returns, umount() may return EBUSY while it performs asynchronous release. See discussion here: page 1, page 2.
• Umounting filesystem. Mounted device may be busy until all data is written to disk.

Even I call sync && echo 2 > /proc/sys/vm/drop_caches and try to drop file caches, it still not work.

See sync(8):

On Linux, sync is only guaranteed to schedule the dirty blocks for writing; it can actually take a short time before all the blocks are finally written. The reboot(8) and halt(8) commands take this into account by sleeping for a few seconds after calling sync(2).

As for /proc/sys/vm/drop_caches, see here:

This is a non-destructive operation and will not free any dirty objects.

Thus, immediately after your command, data may be still queued for write and umounting is not yet finished.

---

Update

However, when asynchronous umounting is in action, kernel will return EBUSY for operations on mounted device, but not for mount point.

So the cases above could not be the reason of your problem :P

---

PS.

Actually I don't understand why the man page states that sync(8) is not synchronous in Linux. It calls sync(2) which states:

According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)