[Bug 201378] Sometimes seeing ENOENT for directories in NFS-mounted ports tree

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201378

            Bug ID: 201378
           Summary: Sometimes seeing ENOENT for directories in NFS-mounted
                    ports tree
           Product: Base System
           Version: 10.0-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: david at catwhisker.org

This is a bit vague, for which I apologize -- in large part, it may be viewed
as a pleas for guidance as to what other information or testing I might do to
help isolate and identify the problem.

I'm filing this under "kern" largely because of my prior experience in
isolating the bug that was addressed by
http://svnweb.freebsd.org/base?view=revision&revision=189287 -- and which had
scarily similar symptoms.

The page at http://www.catwhisker.org/~david/FreeBSD/convert_i386_amd64.html
documents some of my activities where I encountered this issue (about mid-way
down the page).  Summarizing:

Several years ago, I placed my SVN working copy of the ports tree on the
ReadyNAS at home, for use among 3 systems.  One of these systems used svnlite
to update the ports tree daily; each of the three used it for building/updating
ports in place (using portmaster(8)).  I never had a problem with this.

More recently (ref. the above-cited Web page), I made an initial foray into
using poudriere(8) to build custom packages for my installed ports.  After a
few mis-steps, I got it to work for about 10 minutes, at which point I started
seeing errors such as "make: chdir /usr/ports/devel/gsettings-desktop-schemas:
No such file or directory" -- while an "ls" from the same machine showed the
directory.

Eventually, I created a new SVN working copy of the ports tree that was
locally-mounted... and that did not exhibit the failure.

>From what I have seen so far, the effect is 100% reproducible.

That said, it could be a flaw or limitation in the ReadyNAS, or Something Weird
Happened with my network, or ... lots of things, I suppose.

But I seem to have access to an environment where the problem can be re-created
at will, and the machine where the problem is most evident is not needed for
critical activities (and it's reasonably fast), so I'd like to do what I can to
nail this bug down and squash it.

-- 
You are receiving this mail because:
You are the assignee for the bug.