In a test yesterday, it took 3 attempts (each attempt being an
invocations of "rm -fr ~bspace/ports") to actually complete removal of
the hierarchy.
Please note that:
* Done on a locally-mounted file systen (vs. NFS), a single invocation
is sufficient and terminates normally. Each of the above-cited
attempts but the last terminated with a status code of 1 (as well as
a whine that one or more subdirectories was not empty -- this, as a
result of "rm" getting inconsistent information about the status of the
file system).
* Done on either a locally- or NFS-mounted file system in FreeBSD 6.x, a
single invocation is sufficient and terminates normally.
? From the earlier-posted results in 7.x? Not that I can tell. In
each case, the amd(8) child process is forked to attempt an unmount(),
tries it, gets EBUSY, and exits. Meanwhile, rm(1) is descending a
directory tree. It had performed a readdir(), and had been unlinking
files and performing rmdir() against empty subdirectories. It
encounters an entry, issues stat(), finds that it's a subdirectory,
open()s it, gets an FD, issues fstat(), gets results that match those of
the earlier stat(), issues fcntl() against the FD (which returns 0),
tries to issue fstatfs() against the FD *that is still open*, and gets
told ENOENT.
It does differ from the behavior in 8-CURRENT, in that the amd(8) child
process in 8-CURRENT does not appear to get EBUSY. The behavior from
rm(1)'s perspective is very similar, though.
If it would help, I could try getting a ktrace from a 6.x system, but I
expect it will be very boring: the amd(8) child process should get EBUSY
(as it does in 7.x), and nothing else should happen, since the unmount()
attempt failed. And since it failed, rm(1) doesn't get told
inconsistent information, so things Just Work.
I admit that I'm no expert on VFS or much of the rest of the kernel,
for that matter. But what I have observed happening in recent 7.x
is both wrong and a ...
