NetApp FAS6030 VMS problem with free-blocks

[AdriaansenT]

Hi,

I have a problem with the free-blocks on VMS with a NFS mounted NetApp FAS6030 Volume. On Unix all looks oke.

on Unix:
-------------------------------------------
Filesystem Size Used Available Capacity Mounted on
145.43.80.130:/vol/volnfsvms 40G 1777M 38G 5% /mnt
-------------------------------------------

On VMS:

I have mounted the volume as an ODS-5 and an ODS-2 disk.
TCPIP> mount dnfs5: /host="rbndtcfasp001.b2b.regn.net" /path="/vol/volnfsvms" /system /superuser /write /adf=create /structure=5 /auto
TCPIP> mount dnfs2: /host="rbndtcfasp001.b2b.regn.net" /path="/vol/volnfsvms" /s
ystem /superuser /write /adf=create /auto

DNFS2: Mounted 0 rbndt$/vol/v 4194296 1 1
DNFS5: Mounted 0 rbndt$/vol/v 0 1 1

$ write sys$output f$getdvi( "dnfs5", "freeblocks")
4194296
$ write sys$output f$getdvi( "dnfs5", "maxblock")
4194296

$ write sys$output f$getdvi( "dnfs2", "freeblocks")
4194296
$ write sys$output f$getdvi( "dnfs2", "maxblock")
4194296

On the VMS disks the freeblocks = maxblock
(NFS client V2)

The Tru64 machine (NFS client V3)the data
is as follows

Size Used Available Capacity
40G 1777M 38G 5%

On VMS the used blocks are
$ set def dnfs5:[000000]
$ dir/size/grand

Grand total of 1 directory, 11 files, 3619413 blocks. (= 1767 MB)

4194296 blocks = 2047 MB

where is the correct freeblocks attribute?

My TCPIP version is

$ tcpip
TCPIP> show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a AlphaServer 4100 5/600 8MB running OpenVMS V7.3-2



Greetings from Doetinchem, Holland
Tom Adriaansen
IT-Specialist on VMS/Unix and SAN

[Steven Schweda]

I don't know anything, but I'd guess that
"V2" is the problem. The results of a quick
Google search for:
nfs v2 2gb
suggest that you need a v3 NFS client. The
documentation talks about a V3 _server_.

[AdriaansenT]

The NetApp Filer can support NFS clients V2 and V3. I configured it as V3. If the client can not talk Version 3 it skips back to Version 2.

[Steven Schweda]

So you need a better (V3) NFS client. I
don't know if TCPIP offers one, even in a
newer version. (V5.6 seems to be current,
with VMS V8.3).

[Hoff]

Probably not the answer you want...

This looks like it might be a buglet in the TCP/IP Services NFS client.

If you want to investigate the details, take a look at the V2 NFS protocol traffic and see if there's a way to retrieve the freeblock count. I'd expect there is, but that's not a certainty. With multiple nodes active, the freeblock count would have to arrive back at the client fairly regularly to be of any use, or there'd have to be some sort of polling. (It's been a few years since I've been inside the NFSv2 protocol stack.) Why? I'd not expect an $getdvi operation itself to trigger a poll the NFS server for this information. If there's no polling, then there has to be something that periodically updates the freeblock count as new values arrive, or as polling occurs.

There is a cache timeout mechanism on the mount operation, but nothing there looks relevant to this data value.

You could try the newer V5.6 release, though the SPD indicates the client is still NFSv2. The NFS server is now NFSv2 and NFSv3. That's probably going to be a dry well, and it's involving an effort moving from V7.3-2 to V8.3, too. That upgrade would eliminate the need for a PVS contract here, however.

And does the TCP/IP Services NFS client freeblock count work as would be expected with another NFS server? Is this specific to the Network Appliance FAS6030 NAS device, or is this buglet involve the freeblock count from any NFS server?

There's very likely an NFS logging mechanism that might be pressed into service, too.

The nice folks that own the client code involved here are at HP -- if there is a PVS support contract in place, lob a support request at the support center, and let us know the answer.

Stephen Hoffman
HoffmanLabs