Today I switched our F330 from NFS v3 to v2, since it's being used as a News spool and can't really do anything useful with the extra NFS v3 info.
I got a nasty surprise when I found out that the Solaris 2.5.1 statvfs system call no longer returned number of inodes. In fact the fields
u_long f_files; /* total # of file nodes (inodes) */ u_long f_ffree; /* total # of free file nodes */ u_long f_favail; /* # of free nodes avail to non-superuser */
are all set to 4294967295 (ie. -1) on return from statvfs. When I was using NFS v3, these fields had sensible values on return from the call.
I can of course telnet to the NetApp and check the number of inodes directly, but I'd like to do it from the Solaris box which feeds the NetApp with news articles. Any good suggestions?
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
I can of course telnet to the NetApp and check the number of inodes directly, but I'd like to do it from the Solaris box which feeds the NetApp with news articles. Any good suggestions?
I ran into the situation running inn on our Solaris machine, because it tries to do a df -i on the spool directory. They changed df so that it won't allow -i at all on an NFS mounted filesystem! I never tried a statvfs call directly to see if that would work... I had assumed it wouldn't work for v3 either.
I just commented out the df -i check in inn and made sure I had enough inodes on the filer. I didn't pick a *huge* value, but about double what I needed. Inodes don't take up a whole lot of space when compared to the overall filesystem, although a really big inode file can become a performance consideration. You seem to be using some other program that calls statvfs directly (i.e. a C program)... unfortunately, that won't work for v2 at all.
One possibility would be using a script to rsh to the filer from the news server and parse the df -i output...
Bruce