NFS question

[IWANIEC, EDOUARD]

Hi,

I have two machines, A and B. On A there is an exported filesystem, /export/interface. No special options used except "access". It is mounted by both A and B under /interface. I have a filetransfer application running on B, it copies files under /interface and when the transfer is finished it triggers an event for an application running on A. That event on A starts a program also on A which has to read the arrived file under /interface, given by a mask (for example "SC*").

Works quite well but sometimes the program on A doesn't find the given file ("no such file"), which shouldn't occur, because the condition of the start of the program on A is the trigger and the condition of the trigger is the arrival of the file...

What can be the reason of this? I was thinking of some client-side buffering on B: file arrives under B:/interface but this arrival is not immediately reflected on the server, A:/export/interface, and hence on A:/interface.

A is Itanium with HP-UX 11iv2 and B is PA-RISC with HP-UX 11.00.

Thanx in advance,
Laszlo Molnar

[Steven E. Protter]

Shalom Laszlo,

I would speculate that the nature of NFS v3, and how it deals with network disruption is the true cause.

You might want to patch up NFS on the HP-UX 11.00 system.

SEP

[IWANIEC, EDOUARD]

They are on the same LAN segment, so the network shouldn't mean any problem. Or at least I can't make it better, I think.

I was thinking of adding some delay between the arrival of the file and the triggering of the event. This I can easily try, however, not really elegant. :-)

I'll check this NFS patch issue, thanx.

[Dennis Handly]

>when the transfer is finished it triggers an event for an application running on A.

What is the trigger, the creation of another file in the same filesystem?

A better trigger would be the renaming of the original file or a chmod to change from no permissions to the correct permissions. This trigger won't show up until the file is actually there.

[IWANIEC, EDOUARD]

No. I start a remote program on A through ssh from B:
B:$ ssh user@A "/somedirectory/event"

[Dave Olker]

Hi,

The most likely reason for this is attribute caching. My guess is the loopback NFS mount on system A (I assume this is a loopback mount since A is the server for the actual filesystem) is using stale attributes and not refreshing them frequently enough to see when system B has put new files in.

The way to work around this is to mount the filesystem on system A with the "noac" mount option. This will disable all attribute caching for the loopback mount. That should force A to always check the underlying NFS filesystem rather than depend on an attribute cache.

Sounds like you don't need to take the same precaution on B, just A.

Regards,

Dave