Sounds like that should resolve my failure - I'll try to verify from a
nightly tarball when I have the opportunity.

The fix I had in mind would have been to parse the mounts with sufficient
intelligence to match a bind-mount to the original mount and determine it's
type.
I suppose that is still possible if one gets ambitious.

-Paul

On Wed, Sep 12, 2012 at 7:38 AM, Jeff Squyres <jsquy...@cisco.com> wrote:

> I just updated the test to check and see if we get a "none" type of
> filesystem.  If so, we just skip it in the test.
>
>
> On Sep 11, 2012, at 3:50 PM, Paul Hargrove wrote:
>
> > I am NOT running on BG/Q.
> > I am just building for Linux/PPC64 on its front-end node which has very
> recent XLC versions installed.
> >
> > I did look quickly just now at the opal_path_nfs.c test code and see
> that get_mounts() will require non-trivial work to process bind-mounts.
>  The work is "just a matter of coding", but is beyond the scope of what I
> can contribute right now.  I can test as needed, though anybody w/ root on
> a Linux box and an NFS filesystem should be able to reproduce the problem,
> >
> > -Paul [who probably could have avoided confusion by not mentioning BG/Q
> in the first place]
> >
> >
> > On Tue, Sep 11, 2012 at 12:40 PM, Ralph Castain <r...@open-mpi.org>
> wrote:
> > Interesting - I can certainly fix the test so it lets make check
> complete.
> >
> > FWIW: I didn't know we were running on BG/Q - does it work? I assume
> this is with slurm?
> >
> > On Sep 11, 2012, at 12:34 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> >
> >> In testing 1.6.2rc2 on a BG/Q front-end I've encountered the following
> failure from "make check":
> >>
> >>  Failure : Mismatch: input "/soft", expected:0 got:1
> >> SUPPORT: OMPI Test failed: opal_path_nfs() (1 of 20 failed)
> >> FAIL: opal_path_nfs
> >>
> >> What I find digging deeper is that the mount of /soft is a bit unusual
> (at least to me):
> >>
> >> $ grep /soft /etc/fstab
> >> /gpfs/vesta_scratch/software  /soft none  _netdev,bind   0 0
> >> $ mount | grep /soft
> >> /gpfs/vesta_scratch/software on /soft type none (rw,bind,_netdev)
> >> $ grep /soft /proc/mounts
> >> /dev/vesta_scratch /soft gpfs rw,relatime 0 0
> >>
> >>
> >> Looking into the mount man page I find that the "_netdev" is NOT a
> problem, just an keyword used to identify mounts that require network
> access to implement " -O no_netdev" in mount.
> >> The "problem" that opal_path_nfs is encountering is that this is a
> "bind" mount which makes an already mounted fs (or subtree of one)
> available at a second location.
> >>
> >> If I am understanding "expected:0 got:1" correctly this failure shows
> that the TEST is getting this case (bind-mount of GPFS fs) incorrect.
> >> So, this is a BENIGN failure, but distracting (and preventing "make
> check" from completing).
> >>
> >> -Paul
> >>
> >> --
> >> Paul H. Hargrove                          phhargr...@lbl.gov
> >> Future Technologies Group
> >> Computer and Data Sciences Department     Tel: +1-510-495-2352
> >> Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
> >>
> >> _______________________________________________
> >> devel mailing list
> >> de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >
> >
> > _______________________________________________
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >
> >
> >
> > --
> > Paul H. Hargrove                          phhargr...@lbl.gov
> > Future Technologies Group
> > Computer and Data Sciences Department     Tel: +1-510-495-2352
> > Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
> >
> > _______________________________________________
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>



-- 
Paul H. Hargrove                          phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900

Reply via email to