> > > 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.
> >
> > Or patch "df" to print local filesystem sizes as signed -- so
> > that
In the last episode (Feb 04), per...@pluto.rain.com said:
> > 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 d
> 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% reser
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 to
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:
Hi there,
I may have found a clue on this in case anyone's interested:
the FreeBSD box runs on an Intel Atom 230 64-bit CPU
I did more digging and found this:
http://www.freebsd.org/projects/bigdisk/index.html
"An audit is needed to make sure that all reported fields are 64-bit
clean. There
