NFS Client on HPUX / NFS Server Redhat

[Dan Matlock_1]

Have a issue where files are dropped on redhat server file system that is exported via NFS to a hp-ux 11.23 server. the hp-ux server mounts the nfs client file system. So sometimes like last nite 5 files where placed on the linux file system and all are seen, BUT when you go to the corresponding hp-ux server and look at the client mount only 3 of 5 were visible! Now if you 'touch' a file on the hp-ux file system in question, then do a ls... ALL 5 now are displayed. Looks like some kind of caching issue to me on NFS, that until a extra file is created the NFS cache gets flushed and all files are available on the client mount. Just not sure, but seem to have heard of this before... = help if you can. Thanks.

[Shibin_2]

Not sure, whether your issue resolved?

Have you checked the options you used to mount these NFS? Is this only one HPUX server utilizing NFS mount from RedHat ?

[Jayakrishnan G Naik]

Hi Dan,

I have heard about synchronous and asynchronous behavior of nfs exports.
Looks like you have seen it real? I just tried to search about this and see the below information.Find the nfs version you have and if you need you can enable the synchronous exports rather than keeping writes in cache and do it at a later time.


The default export behavior for both NFS Version 2 and Version 3 protocols, "asynchronous". This default permits the server to reply to client requests as soon as it has processed the request and handed it off to the local file system, without waiting for the data to be written to stable storage. This is indicated by the async option denoted in the server's export list. It yields better performance at the cost of possible data corruption if the server reboots while still holding unwritten data and/or metadata in its caches. This possible data corruption is not detectable at the time of occurrence, since the async option instructs the server to lie to the client, telling the client that all data has indeed been written to the stable storage, regardless of the protocol used.

Thanks & Regards
Jayakrishnan G Naik