Re: NFS (& amd?) dysfunction descending a hierarchy

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				david_at_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.