NFS problems with wildcard expansion??
Mike Casey
Here's a report that I've gotten by one of my users (I've verified the
problems myself) regarding one of the disks we're exporting from one
machine to another (we've had problems with a similar, identical disk).
It is an 18GB drive sold to us directly by SGI, and installed in an
Origin 200.
The machines mentioned below are as follows:
Liverpool: SGI Origin 200 runing IRIX 6.5.3m
Washabuck: Sun Ultra 10 running SunOS 5.6
Silver: " " " " " "
Roseway: " " " " " "
Skye: Sun SPARC 10 running SunOS 5.5.1
The disk is physically mounted on Liverpool, and is exported (NFS) to
the others. The problem could be either with the SGIs or the Suns, but
given that we have many disks mounted on different machines on our LAN,
and only the ones mounted on the SGIs seem to be giving difficulty
suggest there must be some incompatibility between the SGI and Suns,
although given that it only shows up on some machines, and not others,
really is puzzling. I haven't been able to isolate why one machine
responds differently than another.
Btw, the disk is brand new. The content is stuff we just recently
copied over from another disk which was attached to Silver. The user
was testing to make sure everything had transferred properly. The mount
point for the drive on all remote machines is
/data/po/model which is a symbolic link to /autofs/data/model.
Anyway, here's the report:
--------------------------------------------------------------------------------
<><>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
1) This is quite random, but depending on platform, * entry either
works or does not work -- maybe related to filename length as
in 3) below.
On Washabuck:
Washabuck# ls /data/po/model/drew/shw/freeslip
runfiles.tar.gz src.tar.gz
Washabuck# ls /data/po/model/drew/shw/freeslip/*
/data/po/model/drew/shw/freeslip/*: No such file or directory
On Silver:
Silver# ls /data/po/model/drew/shw/freeslip/*
/data/po/model/drew/shw/freeslip/runfiles.tar.gz
/data/po/model/drew/shw/freeslip/src.tar.gz
On Roseway:
Roseway# ls /data/po/model/drew/shw/freeslip/*
/data/po/model/drew/shw/freeslip/*: No such file or directory
On Skye:
Skye# ls /data/po/model/drew/shw/freeslip/*
/data/po/model/drew/shw/freeslip/runfiles.tar.gz
/data/po/model/drew/shw/freeslip/src.tar.gz
<><>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
2)
On Skye ls on this directory fails resulting in this error message:
[All other machines seem fine]
Skye# ls /data/po/model/drew/baro/coads
NFS readdir+ failed for server liverpool: error 2 (RPC: Can't decode
result)
NFS readdir failed for server liverpool: error 2 (RPC: Can't decode
result)
<><>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
3)
On Washabuck -- * entry in this directory only expands to the shorter
filenames.
Washabuck# ls /data/po/model/drew/climate/logfiles/
gm301.log gme301.com.log gn002.com.log gna101.com.log
go001.com.log
gma001.log gme301.log gn002.log gna101.log
go001.log
gmb001.log gmf001.com.log gn101.com.log gnb001.com.log
go101.com.log
gmc001.log gmf001.log gn101.log gnb001.log
go101.log
gmd001.log gmg001.com.log gn201.com.log gnf001.com.log
gmd301.com.log gmg001.log gn201.log gnf001.log
gmd301.log gn001.com.log gna001.com.log gng001.com.log
gme001.log gn001.log gna001.log gng101.log
Washabuck# > ls /data/po/model/drew/climate/logfiles/*
/data/po/model/drew/climate/logfiles/gm301.log
/data/po/model/drew/climate/logfiles/gn001.log
/data/po/model/drew/climate/logfiles/gn002.log
/data/po/model/drew/climate/logfiles/gn101.log
/data/po/model/drew/climate/logfiles/go001.log
/data/po/model/drew/climate/logfiles/go101.log
Obviously all are probably related, although it has nothing to
do with the number of files in the directory (a common cause of *
substition failure) -- but does seem to be related to filename length.
--------------------------------------------------------------------------
I've also noticed that wildcard expansion really doesn't seem to like
files
with multiple expansions on some of the machines (e.g. ".com.log" above
as opposed to just ".log"). File completion also fails on these files
(not surprising)on the machines having difficulty.
Anybody have any thoughts on what might be causing these difficulties?
Help would be
greatly appreciated. Right now it has not stopped any of us from doing
work,
but if one isn't aware of the problem, or forgets about it, you can see
how
it could cause problems (trying to copy files using wildcards for
example).
Thanks for any help.
Cheers,
Mike Casey
___________________________________________________________________________
Mike Casey
Research Assistant
Department of Oceanography
Dalhousie University
Halifax, Nova Scotia, Canada
email: mca...@phys.ocean.dal.ca
work:phone: (902)494-2976
FAX: (902)494-2885
___________________________________________________________________________
Joseph Michaud
exporting the filesystem from the SGI with the "32bitclients"
option to see if that helps.
See the exports(4) man page on SGI.
Joe
Mike Casey <mca...@phys.ocean.dal.ca> wrote:
>
> Here's a report that I've gotten by one of my users (I've verified the
> problems myself) regarding one of the disks we're exporting from one
> machine to another (we've had problems with a similar, identical disk).
> It is an 18GB drive sold to us directly by SGI, and installed in an
> Origin 200.
>
> The machines mentioned below are as follows:
>
> Liverpool: SGI Origin 200 runing IRIX 6.5.3m
> Washabuck: Sun Ultra 10 running SunOS 5.6
> Silver: " " " " " "
> Roseway: " " " " " "
> Skye: Sun SPARC 10 running SunOS 5.5.1
>
> The disk is physically mounted on Liverpool, and is exported (NFS) to
> the others. The problem could be either with the SGIs or the Suns, but
> given that we have many disks mounted on different machines on our LAN,
> and only the ones mounted on the SGIs seem to be giving difficulty
> suggest there must be some incompatibility between the SGI and Suns,
> although given that it only shows up on some machines, and not others,
> really is puzzling. I haven't been able to isolate why one machine
> responds differently than another.
> ...
> Anyway, here's the report:
>
> --------------------------------------------------------------------------------
>
> <><>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> ...
> 2)
>
> On Skye ls on this directory fails resulting in this error message:
> [All other machines seem fine]
>
> Skye# ls /data/po/model/drew/baro/coads
> NFS readdir+ failed for server liverpool: error 2 (RPC: Can't decode
> result)
> NFS readdir failed for server liverpool: error 2 (RPC: Can't decode
> result)
>
--
------------------------------------------------------------------------
Joseph Michaud SGI - Applications Consulting
jmic...@boston.sgi.com x483-2255 978-562-4800
Mark Bartelt
>> Perhaps the older Sun OSes don't grok NFS version 3. Try
>> exporting the filesystem from the SGI with the "32bitclients"
>> option to see if that helps.
Actually, when I first ran into this problem (more than year and a half
ago), a couple people provided useful advice. The problem is not that
the older SunOSes don't support NFSv3. If they didn't, the client and
server would negotiate to use v2. The problem is that Sun, or SGI, or
(quite likely) both have (or at least had) some bugs in their v3 code.
I have no idea where the bug(s) {is,are} (I've seen finger pointing by
both vendors), but in any case, the workaround is straightforward.
Exporting with "32bitclients" is one way to work around the problem. Or
alternatively, you could mount using the "vers=2" option" on the clients.
Mark Bartelt 626 395 2522
Center for Advanced Computing Research ma...@cacr.caltech.edu
California Institute of Technology http://www.cacr.caltech.edu/~mark
"Nur eine Waffel taugt!" -- Parsifal, in an Eggo commercial
Mike O'Connor
Mark Bartelt <ma...@cacr.caltech.edu> wrote:
:In his reply to Mike Casey's problem report, Joseph Michaud suggested
:
:>> Perhaps the older Sun OSes don't grok NFS version 3. Try
:>> exporting the filesystem from the SGI with the "32bitclients"
:>> option to see if that helps.
:
:Actually, when I first ran into this problem (more than year and a half
:ago), a couple people provided useful advice. The problem is not that
:the older SunOSes don't support NFSv3. If they didn't, the client and
:server would negotiate to use v2. The problem is that Sun, or SGI, or
:(quite likely) both have (or at least had) some bugs in their v3 code.
:I have no idea where the bug(s) {is,are} (I've seen finger pointing by
:both vendors), but in any case, the workaround is straightforward.
Both have had many NFS bugs, but the bug that causes -32bitclients to
be necessary is at the client end. The client should deal with an
"opaque" NFS cookie of arbitrary size, but many clients don't. When
IRIX started handing out 64-bit cookies as part of NFS3/XFS/64-bit
efforts, it ran into this.
:Exporting with "32bitclients" is one way to work around the problem. Or
:alternatively, you could mount using the "vers=2" option" on the clients.
--
Michael J. O'Connor | WWW: http://dojo.mi.org/~mjo/ | Email: m...@dojo.mi.org
InterNIC WHOIS: MJO | (has my PGP & Geek Code info) | Phone: +1 248-848-4481