I was starting to suspect that it might be something along these lines. NFSv3 hasn't been possible so far because the Terastation hacked firmware on this particular platform (TS Pro v1) doesn't seem to play nice with kernel-level nfs (userland nfs only has packages for v2, and I've been too intimidated to approach the idea of rolling my own so far.)

This explains a lot -- I thought maybe it might be the result of me running normal 32-bit i386 release on a 64-bit CPU. I will see if I can get NFS3 working.

(I guess MacOS X/Mach/BSDI treat the size value as unsigned...)


On 3 Feb 2009, at 22:53, Dan Nelson wrote:

In the last episode (Feb 03), John Morgan Salomon said:
On 3 Feb 2009, at 19:21, John Morgan Salomon wrote:
Hi there,

I'm facing an odd problem with an NFSv2 mount.  I'm using userland
nfsd from a Buffalo TeraStation Pro v1 NAS, running PPC Linux 2.4.20.

r...@leviathan:~# uname -a
Linux LEVIATHAN 2.4.20_mvl31-ppc_terastation #3 Tue Jul 18 09:29:11 JST 2006 ppc GNU/Linux

I am sharing the following filesystem:

r...@leviathan:~# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
<local filesystems>
/dev/md1             1755708928 979032844 776676084  56% /mnt/array1

Mounting this on a FreeBSD 7.1 client:

behemoth# mount /data
behemoth# df -k
Filesystem                    1024-blocks        Used     Avail
Capacity  Mounted on
<local filesystems>  -391774720 -1168450804 776676084

I did more digging and found this:


"An audit is needed to make sure that all reported fields are 64-bit
clean. There are reports with certain fields being incorrect or
negative with NFS volumes, which could either be an NFS or df problem."

Not sure where to go now, as the last entry in that project is dated
2005 -- again, any tips welcome.

The real problem is that NFSv2 only provides a 32-bit field for filesystem size, and multiplies that by the reported blocksize. Most NFS servers claim 512-byte blocks no matter what the underlying filessytem has, so in your
case that would result in the filesystem size being reported as
1755708928*1024/512 = 3511417856 blocks. This number is larger than 2^31, which techinically isn't a problem because the NFSv2 spec says that the filesystem size is unsigned. FreeBSD treats it as signed, though, so it can display "negative" free space when root starts using its 8% reserve, so your
unsigned 3511417856 gets printed as a signed -783549440, which messes
everything up.

NFSv3 uses 64-bit fields for those size values, so just mount with NFSv3 (which actually is the default on FreeBSD; maybe you have it disabled on your TeraStation for some reason), and you should get correct filesystem stats, as well as better performance and the ability to work with files over

Alternatively, you could rebuild "df" to print its numbers as unsigned
instead of signed. Just watch out if your local filesystems start eating
into their 8% reserve, since they'll start reporting huge values.

        Dan Nelson
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org "

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to