Don't understand NFS syncing in TCPIP 5.7 ECO 5

All types of networks, network stacks, and protocols supported by OpenVMS.
Post Reply

Topic author
jonesd
Contributor
Posts: 14
Joined: Mon Aug 09, 2021 7:59 pm
Reputation: 0
Status: Offline

Don't understand NFS syncing in TCPIP 5.7 ECO 5

Post by jonesd » Thu Jan 06, 2022 6:21 am

In my home setup, I have a process on a Debian linux host that writes about 4 times an hour to a log file in a directory that it also serves to the network via NFS. If I want to check for recent events, I run a report program on my OpenVMS host that reads this log file and summarizes the activity. The NFS share is mounted readonly on the OpenVMS side. This has worked reliably for years under HP VMS 8.4 and the TCPIP 5.7-13 NFS client, but now has strange behavior under VSI 8.4-L2 and TCPIP 5.7 EC0.

When my program reads the file, it gets a stale version of where the end of file is, missing up to many hours of updates. Directory/full of the file shows modified time and size matching what the program reads. If I then TYPE or COPY this file, suddenly everthing syncs. TYPE shows the whole file, the reports program can read the whole file, and DIRECTORY/FULL shows the correct size and modify date. I wrote a test program that instead of using the CRTL makes direct RMS calls to read the file, but it behaves like my report program and doesn't cause a sync.

What are TYPE and COPY doing different? How can I make my programs force the DNFS ACP to refresh the file data?

Added in 2 hours 50 minutes 57 seconds:
I wrote a second test program which instead of a simple SYS$OPEN call first calls SYS$PARSE+SYS$SEARCH and then calls SYS$OPEN with the open-by-NAM-block option. This program somehow forces the NFS client to update it's view of the NFS share and read all the data written by the other host.

This would be a rather intrusive fix to my report program.


hein
Active Contributor
Posts: 25
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: Don't understand NFS syncing in TCPIP 5.7 ECO 5

Post by hein » Thu Jan 06, 2022 11:56 pm

I know noting much about NFS always just hoping it works.
This problem sounds like a caching issue.

>> direct RMS calls to read the file, but it behaves like my report program and doesn't cause a sync.
Try to add the SHR=PUT (or any other write access) to the RMS test program to allow writers.
If that works add that to you main program open code as an option.

>> SYS$PARSE+SYS$SEARCH and then calls SYS$OPEN with the open-by-NAM-block option.
:
>> This would be a rather intrusive fix to my report program.

You may find that the Parse+Search alone is enough to flush a cache, possibly that open is also needed but thjen just close it and and allow the normal existing code to hopefully act as desired.
They could be a reasonably focused subroutine addition, with no other change to the main code path.

The question remains of course what changes - by accident or by design, and whether there is a (mount?) option to revert to the old behavior.

fwiw,
Hein

User avatar

volkerhalle
Valued Contributor
Posts: 58
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Don't understand NFS syncing in TCPIP 5.7 ECO 5

Post by volkerhalle » Mon Jan 10, 2022 7:08 am

David,

you can use TCPIP NFS client tracing like this:

$ DEFINE/SYS TCPIPWARE_CNFS_TRACE *
$ DEFINE/SYS TCPIPWARE_CNFS_LOGFILE sys$manager:dnfs_trace.log

Then mount the NFS share, do your testing and dismount the NFS share. Then you can look at the DNFS_TRACE.LOG file.

re: TCPIP MOUNT qualifiers: did you try the /SYNC=FILE_SYNC qualifier ?

Volker.


Topic author
jonesd
Contributor
Posts: 14
Joined: Mon Aug 09, 2021 7:59 pm
Reputation: 0
Status: Offline

Re: Don't understand NFS syncing in TCPIP 5.7 ECO 5

Post by jonesd » Wed Jan 12, 2022 10:46 am

volkerhalle wrote:
Mon Jan 10, 2022 7:08 am
David,

you can use TCPIP NFS client tracing like this:

$ DEFINE/SYS TCPIPWARE_CNFS_TRACE *
$ DEFINE/SYS TCPIPWARE_CNFS_LOGFILE sys$manager:dnfs_trace.log

Then mount the NFS share, do your testing and dismount the NFS share. Then you can look at the DNFS_TRACE.LOG file.

re: TCPIP MOUNT qualifiers: did you try the /SYNC=FILE_SYNC qualifier ?
The trace log is hard to interpret without the ACP source code to follow what it is doing. It's full of TLAs that I don't know what they mean (e.g. ADB, AID, FSO). I made TCPIPWARE_CNFS_LOGFILE a mailbox, which the test programs also write messages to so I can match up my RMS calls with the DNSFnnACP activity. I can see where the sys$open calls cause a READ_ATTRIBUTES that gets the file dates, but can't identify any preceding activity in the open-by-NAM-block case that makes it get the current revision date.

Timeline of the latest test case:
  • 07:31:36.00 basic sys$open sees target file with REVDATE 07:11:40.48
  • 07:39:40.59 basic sys$open still sees REVDATE 07:11:40.48
  • 07:40:07.25 sys$open/NAM block sees file with update time of 07:35:39.47
The second open, occurring at 39:40, should have seen the updates to the file added at 35:39 but didn't.

The /sync=file_sync doesn't change this observed behavior.

Post Reply