On Fri, Dec 12, 2008 at 03:41:29PM +0200, Kostik Belousov wrote: > ... > > * At 1229033597.287187 it issues an fstatfs() against FD 4; the > > unsuccessful return is at 1229033597.287195, claiming ENOENT. > > > > Say WHAT??!? > ... > > But is this error transient or permanent ? I.e., would restart of rm > successful or failing ?
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. In other words, this is a regression. > Anyway, this error looks different too. ? 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 regression. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpNoDLDaFr3Z.pgp
Description: PGP signature
