SEO

I have a weird problem with NFS on an AIX system.

The configuration is this:
AIX 5.1, acting as client.
Linux as the server.

I have a directory on the Linux system successfully mounted on the AIX
system. I can see it, read it, etc. manually. However, when I try to
access it from a script, I often get spurious failures. For example,

[[ -d someDirectory ]] || echo This will fail
[[ -d someDirectory ]] && echo This will succeed

In other words, the first -d doesn't find the directory, but when it's
repeated immediately, it does. This is immediately after successful
references to the parent of someDirectory; in fact, the script that's
running on the AIX box is coming from a sibling of the directory I'm
checking. If it matters, this is all through a symlink, i.e. on the
AIX box, I have ~/remote as a symlink to /net/linux/....

I've done one check using nfsstat, and didn't see anything unusual, not
that I'm an expert on using nfsstat. I didn't see anything in the way
of retransmit errors.

The only previous note I've been able to find that looks familiar is
http://supportforum.sun.com/network/...rid=0#msg_2067
,
where the server side is a Sun box, not a Linux box, but the client is
an older AIX box (4.3.3, to be exact). So this makes me think the
problem in on the AIX side. I can't easily upgrade the AIX box, as
it's a loaner from a customer for a project.

Any help would be appreciated. In the mean time, I'm working around
the problem by doing ls -R >/dev/null on the directory before any
tests.

Many thanks,

Gary

not sure I am understanding your testcase here....

[[ -d /tmp ]] || echo This will fail
--> nothing

[[ -d /tmp ]] && echo This will succeed
This will succeed

Is that your testcase ? have you tried running it on a normal directory
? i must be missing something because one is a logical OR and the other
is a logical AND.

Can you post some more test data to backup your case please ... its
nearly xmas and my Brain is on shutdown mode

Cheers
Mark Taylor

Gary <gfyho@yahoo.com> wrote:
> [[ -d someDirectory ]] || echo This will fail
> [[ -d someDirectory ]] && echo This will succeed
>
> In other words, the first -d doesn't find the directory, but when it's
> repeated immediately, it does.

Maybe you can get some useful information from an AIX system trace
while this happens.
Some system call must return with an error once and work the
next time. Maybe looking at the return code helps!

Yours,
Laurenz Albe

Mark Taylor wrote:
> not sure I am understanding your testcase here....
>
> [[ -d /tmp ]] || echo This will fail
> --> nothing
>
> [[ -d /tmp ]] && echo This will succeed
> This will succeed
>
> Is that your testcase ? have you tried running it on a normal
directory

Sorry I wasn't clearer.

The test case is designed to show the inconsistency. Both messages
will print, even though the sense of the conjunction is swapped. In
other words, the first -d fails, causing the message to print. The
second -d succeeds, causing its message to print as well.

If you do it on an ordinary directory, only one message will print.
Gary

ok, got ya now... what level of bos.net.nfs.client are you running ?

also, as detailled above, run trace or truss to see where the faliure
occcurs (truss is a little easier to run)

truss -e -f -o truss.out [[ -d /somenfsdir ]] || echo This will fail
Rgds
Mark Taylor

In answer to the bos.net.nfs.client question, it's 5.1.0.57.
I'll try the truss suggestion.

Thanks,

Gary

The interesting part of the truss output is:

kioctl(1, 22528, 0x00000000, 0x00000000) Err#64 EOPNOTSUPP
kioctl(1, 1074295912, 0x2FF226F8, 0x00000000) Err#64 EOPNOTSUPP
statx("/home/....", 0x200CC240, 128, 010) Err#52 ESTALE

I suspect the first two are irrelevant because they're on fd 1, but the
last makes some sense. Since I'm performing remote operations on
several systems, my next step is to try reordering things so that I
deal with one platform at a time before stepping to the next.

Gary