Re: Who needs these silly statfs changes...
Peter Edwards wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! [ ... ] The NFS protocols have unsigned fields where statfs has signed equivalents: NFS can't represent negative available disk space ( Without the knowledge of the underlying filesystem on the server, negative free space is a little nonsensical anyway, I suppose) The attached patch stops the NFS server assigning negative values to unsigned fields in the statfs response, and works against my local solaris box. Seem reasonable? I disagree. The intent of the negative number from df is to subtract the amount used from the total amount available, in order to get the amount remaining. When this results in a negative number, what it's saying is that you are using up space from the free reserve. This is an artifact of implementation on the server, and should not be second-guessed by the client. The problem in this case is on the client, not the server, in not doing the conversion as an unsigned operation. The place for the subtraction to occur is in the df program. In other words, the statfs-f_bavail should be recalculated locally from the values of statfs-f_blocks and statfs-f_bfree, not used directly out of the (unsigned) NFS values... or the values should be converted to signed values coming out of NFS prior to their sign extension to the size type. On a slightly related note, the standards mandated interfaces say that the values should be fsblkcnt_t, which must be an unsigned integer type. This coordinates well with my point of the sign conversion on legacy interface needing to happen at presentation time. Also, if you read the ISO C99 standard, you'll see that on an ILP32 system, there is no way to legitimately define an integer type in excess of 32 bits, unless long is larger than 32 bits (see section 3.6), so defining these things as 64 bits without compiler changes is wrong anyway. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
(CC's trimmed, I'm sure I'm boring people at this stage.) Peter Edwards wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! [ ... ] The NFS protocols have unsigned fields where statfs has signed equivalents: NFS can't represent negative available disk space ( Without the knowledge of the underlying filesystem on the server, negative free space is a little nonsensical anyway, I suppose) The attached patch stops the NFS server assigning negative values to unsigned fields in the statfs response, and works against my local solaris box. Seem reasonable? I disagree. The intent of the negative number from df is to subtract the amount used from the total amount available, in order to get the amount remaining. I just don't see how you can possibly infer from the NFS spec that abytes is anything other than an unsigned quantity. I just think assuming the client will interpret a massive value as probably negative is a bit of a leap of faith. This is an artifact of implementation on the server, and should not be second-guessed by the client. If the server tells the client that there are 2^64 - 1 bytes remaining on the server, it's not second guessing anything by presenting that to the user. The problem in this case is on the client, not the server, in not doing the conversion as an unsigned operation. The place for the subtraction to occur is in the df program. In other words, the statfs-f_bavail should be recalculated locally from the values of statfs-f_blocks and statfs-f_bfree, not used directly out of the (unsigned) NFS values... or the values should be converted to signed values coming out of NFS prior to their sign extension to the size type. (Note that NFS also gives a fbytes, indicating the number of free bytes, as opposed to available to a particular user) bavail can really only be worked out by the server. The server is reserving a percentage for non-root user. The client can't work out what that reserve percentage is. On a slightly related note, the standards mandated interfaces say that the values should be fsblkcnt_t, which must be an unsigned integer type. This coordinates well with my point of the sign conversion on legacy interface needing to happen at presentation time. Maybe we're talking across each other. That's my main point: the server shouldn't put huge values in an unsigned field and expect the client to interpret them in a way that the spec sets no precedent for. Also, if you read the ISO C99 standard, you'll see that on an ILP32 system, there is no way to legitimately define an integer type in excess of 32 bits, unless long is larger than 32 bits (see section 3.6), so defining these things as 64 bits without compiler changes is wrong anyway. As far as implementing NFS is concerned, that's probably not relevant: It doesn't have to be implemented in ISO C. The FreeBSD compiler provides a 64-bit integer type that its implementation is free to use :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
Bruce Evans wrote: I just got around to testing the patch in that reply: [ ... ] This seems to work. On a 2TB-epsilon ffs1 file system (*) on an md malloc disk (**): Try it again. This time, take the remote FS below its free reserve as the root user, and see what the client machine reports. Compare the results to an identical local FS. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
[EMAIL PROTECTED] wrote: I disagree. The intent of the negative number from df is to subtract the amount used from the total amount available, in order to get the amount remaining. I just don't see how you can possibly infer from the NFS spec that abytes is anything other than an unsigned quantity. I just think assuming the client will interpret a massive value as probably negative is a bit of a leap of faith. I'm not. I'm saying that the value needs to be zero on the server, if it's zero. In reality, the negative value that's being stuffed is wrong; it's possible to be root over NFS to a server that supports the idea of a free reserve. If you represent the free reserve over the wire, then you have the problem; if you don't represent the free reserve over the wire, then you don't. The problem here is that you are taking the reported value for the available bytes *after* the local free reserve (if any) is taken into account, and exporting it over the wire. This is an artifact of implementation on the server, and should not be second-guessed by the client. If the server tells the client that there are 2^64 - 1 bytes remaining on the server, it's not second guessing anything by presenting that to the user. The server can't tell the client that, because that's outside the range that's representable witin the NFS protocol. Now if you were willing to limit yourself to sizeof(abytes), then you have a valid argument. The problem in this case is on the client, not the server, in not doing the conversion as an unsigned operation. The place for the subtraction to occur is in the df program. In other words, the statfs-f_bavail should be recalculated locally from the values of statfs-f_blocks and statfs-f_bfree, not used directly out of the (unsigned) NFS values... or the values should be converted to signed values coming out of NFS prior to their sign extension to the size type. (Note that NFS also gives a fbytes, indicating the number of free bytes, as opposed to available to a particular user) bavail can really only be worked out by the server. The server is reserving a percentage for non-root user. The client can't work out what that reserve percentage is. Sure, fine, work it out. And report 0 if the value is negative on the server after you work it out. In theory, it's not possible for this value to be less than 0 on the server, unlss you are doing your calculations wrong, since you can't assume the credential to be used by the client user, the state of the -maproot option globally, for all mounts, or that the client is familiar with the concept of a free reserve. So the only server problem, if there is one, is that the server should report the number of unallocated bytes, ignoring the free reserve. On a slightly related note, the standards mandated interfaces say that the values should be fsblkcnt_t, which must be an unsigned integer type. This coordinates well with my point of the sign conversion on legacy interface needing to happen at presentation time. Maybe we're talking across each other. That's my main point: the server shouldn't put huge values in an unsigned field and expect the client to interpret them in a way that the spec sets no precedent for. It depends; are these values huge because they're huge, or are they huge because that's what you get when you convert a negative signed value to an unsigned value as bits, without clamping negative values to 0? I think Bruce Evans' post on type conversion is relevent here. The largest value you should ever stuff in it is MAX_UINT (or whatever sized type maps to sizeof(abytes), and the smallest is 0. If you do that, the value is absolutely correct when going over the wire, and whether or not remote(MAX_UNIT) signed local representation is a problem for the client. Also, if you read the ISO C99 standard, you'll see that on an ILP32 system, there is no way to legitimately define an integer type in excess of 32 bits, unless long is larger than 32 bits (see section 3.6), so defining these things as 64 bits without compiler changes is wrong anyway. As far as implementing NFS is concerned, that's probably not relevant: It doesn't have to be implemented in ISO C. The FreeBSD compiler provides a 64-bit integer type that its implementation is free to use :-) You misunderstand: statfs/fstatfs is not a standard interface. It may be time to deprecate it in favor of statvfs/fstatvfs. If we did that, the values become unsigned, and we could (maybe) ignore the problem (everywhere except the traditional reporting of negative blocks available in df, which could be handled by an unsigned compare and a %c that got ' ' or '-'). Alternately, we ned to acknowledge that the interface that's being tried for is outside the scope of standards entirely. Doing this is a real pain, though, since idiots will use it to get more resolution, and it will proagate. Probably the best thing would be to
Re: Who needs these silly statfs changes...
On Sat, 15 Nov 2003, Terry Lambert wrote: Bruce Evans wrote: I just got around to testing the patch in that reply: [ ... ] This seems to work. On a 2TB-epsilon ffs1 file system (*) on an md malloc disk (**): Try it again. This time, take the remote FS below its free reserve as the root user, and see what the client machine reports. Compare the results to an identical local FS. Er, that is the main thing that the test did. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote: Bruce Evans wrote: ... I just got around to testing the patch in that reply: ... Your patch to nfs_vfsops won't apply to my Solaris kernel :-) The protocol says abytes is unsigned, so the server shouldn't be lying by sending a huge positive value for available space on a full filesystem. No? Possibly not, but the protocol is broken if it actually requires that. What makes you say that? I would think the utility of negative counts for disk sizes and available spaces is marginal. Solaris, POSIX, and NFS seem to get on fine without it. What am I (and they) missing? Well, the f_bavail field (not to mention all the other fields (until recently, sigh)) has always been signed and does go negative in BSD's statfs, so the protocol is broken if it can't support negative values in it. The type pun to negative values is in most versions of BSD: [snip code snippets and bug] That's great for interacting with other BSDs, but it still abusing the protocol. As filesystems with approaching 2^64 bytes become possible it probably has more of an impact. 2^63 won't be needed any time soon. This problem was more serious with nfsv2 when file systems reached 2^31 bytes not so long ago. The current problem is actually more with non-BSD clients and a BSD server. The BSD server will send the negative values and the non-BSD client may convert them to huge positive ones. Non-BSD servers presumably won't send negative values. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
Bernd Walter wrote: On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote: On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it possible that rot13:/mnt2 has negative free space? (ie it's into the 8-10% reserved area). Yes, that's precisely what it is..the bug is either in df or the kernel (I suspect the latter, i.e. something in the nfs code). And it's nothing new - I'm seeing this since several years now. The NFS protocols have unsigned fields where statfs has signed equivalents: NFS can't represent negative available disk space ( Without the knowledge of the underlying filesystem on the server, negative free space is a little nonsensical anyway, I suppose) The attached patch stops the NFS server assigning negative values to unsigned fields in the statfs response, and works against my local solaris box. Seem reasonable? Index: nfs_serv.c === RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/nfsserver/nfs_serv.c,v retrieving revision 1.137 diff -u -r1.137 nfs_serv.c --- nfs_serv.c 24 Oct 2003 18:36:49 - 1.137 +++ nfs_serv.c 14 Nov 2003 13:27:42 - @@ -3812,7 +3812,7 @@ tval = (u_quad_t)sf-f_bfree; tval *= (u_quad_t)sf-f_bsize; txdr_hyper(tval, sfp-sf_fbytes); - tval = (u_quad_t)sf-f_bavail; + tval = sf-f_bavail 0 ? (u_quad_t)sf-f_bavail : 0; tval *= (u_quad_t)sf-f_bsize; txdr_hyper(tval, sfp-sf_abytes); sfp-sf_tfiles.nfsuquad[0] = 0; @@ -3827,7 +3827,8 @@ sfp-sf_bsize = txdr_unsigned(sf-f_bsize); sfp-sf_blocks = txdr_unsigned(sf-f_blocks); sfp-sf_bfree = txdr_unsigned(sf-f_bfree); - sfp-sf_bavail = txdr_unsigned(sf-f_bavail); + sfp-sf_bavail = txdr_unsigned(sf-f_bavail 0 ? + sf-f_bavail : 0); } nfsmout: if (vp) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
On Fri, 14 Nov 2003, Peter Edwards wrote:
Bernd Walter wrote:
On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote:
On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote:
On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
...my sparc machine reports that my i386 nfs server has 15 exabytes of
free space!
enigma# df -k
Filesystem 1K-blocks Used Avail Capacity Mounted on
rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2
18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it
possible that rot13:/mnt2 has negative free space? (ie it's into the
8-10% reserved area).
Yes, that's precisely what it is..the bug is either in df or the
kernel (I suspect the latter, i.e. something in the nfs code).
And it's nothing new - I'm seeing this since several years now.
The NFS protocols have unsigned fields where statfs has signed
equivalents: NFS can't represent negative available disk space ( Without
the knowledge of the underlying filesystem on the server, negative free
space is a little nonsensical anyway, I suppose)
The attached patch stops the NFS server assigning negative values to
unsigned fields in the statfs response, and works against my local
solaris box. Seem reasonable?
The client attampts to fix this by pretending that the unsigned fields
are signed. -current tries to do more to support file system sizes larger
that 1TB, but the code for this is not even wrong except it may be wrong
enough to break the negative values. See my reply to one of the PRs
for more details.
I just got around to testing the patch in that reply:
%%%
Index: nfs_vfsops.c
===
RCS file: /home/ncvs/src/sys/nfsclient/nfs_vfsops.c,v
retrieving revision 1.143
diff -u -2 -r1.143 nfs_vfsops.c
--- nfs_vfsops.c12 Nov 2003 02:54:46 - 1.143
+++ nfs_vfsops.c12 Nov 2003 14:37:46 -
@@ -223,5 +223,5 @@
struct mbuf *mreq, *mrep, *md, *mb;
struct nfsnode *np;
- u_quad_t tquad;
+ quad_t tquad;
int bsize;
@@ -254,19 +254,19 @@
for (bsize = NFS_FABLKSIZE; ; bsize *= 2) {
sbp-f_bsize = bsize;
- tquad = fxdr_hyper(sfp-sf_tbytes);
- if (((long)(tquad / bsize) LONG_MAX) ||
- ((long)(tquad / bsize) LONG_MIN))
+ tquad = (quad_t)fxdr_hyper(sfp-sf_tbytes) / bsize;
+ if (bsize = INT_MAX / 2
+ (tquad LONG_MAX || tquad LONG_MIN))
continue;
- sbp-f_blocks = tquad / bsize;
- tquad = fxdr_hyper(sfp-sf_fbytes);
- if (((long)(tquad / bsize) LONG_MAX) ||
- ((long)(tquad / bsize) LONG_MIN))
+ sbp-f_blocks = tquad;
+ tquad = (quad_t)fxdr_hyper(sfp-sf_fbytes) / bsize;
+ if (bsize = INT_MAX / 2
+ (tquad LONG_MAX || tquad LONG_MIN))
continue;
- sbp-f_bfree = tquad / bsize;
- tquad = fxdr_hyper(sfp-sf_abytes);
- if (((long)(tquad / bsize) LONG_MAX) ||
- ((long)(tquad / bsize) LONG_MIN))
+ sbp-f_bfree = tquad;
+ tquad = (quad_t)fxdr_hyper(sfp-sf_abytes) / bsize;
+ if (bsize = INT_MAX / 2
+ (tquad LONG_MAX || tquad LONG_MIN))
continue;
- sbp-f_bavail = tquad / bsize;
+ sbp-f_bavail = tquad;
sbp-f_files = (fxdr_unsigned(int32_t,
sfp-sf_tfiles.nfsuquad[1]) 0x7fff);
%%%
This seems to work. On a 2TB-epsilon ffs1 file system (*) on an md malloc
disk (**):
server:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 21474168960 1975624000 0%/b
client:
Filesystem 1024-blocks Used Avail Capacity Mounted on
besplex:/b 21474168960 1975624000 0%/b
These are 1K-blocks so their count fits in an int32_t, but the count in
512-blocks is too large for an int32_t so the scaling must be helping.
With newfs -m 100 (***) to get near negative free space:
server:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 21474168960 5696 0%/b
client:
Filesystem 1K-blocks Used Avail Capacity Mounted on
besplex:/b 21474168960 5696 0%/b
After using up all the free space by creating a 6MB file:
server:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 2147416896 6208 -512 109%/b
client:
Filesystem 1024-blocks Used Avail Capacity Mounted on
besplex:/b 2147416896 6208 -512 109%
Re: Who needs these silly statfs changes...
Bruce Evans wrote: On Fri, 14 Nov 2003, Peter Edwards wrote: Bernd Walter wrote: On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote: On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on rot13:/mnt2 56595176 54032286 18014398507517260 0% /rot13/mnt2 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it possible that rot13:/mnt2 has negative free space? (ie it's into the 8-10% reserved area). Yes, that's precisely what it is..the bug is either in df or the kernel (I suspect the latter, i.e. something in the nfs code). And it's nothing new - I'm seeing this since several years now. The NFS protocols have unsigned fields where statfs has signed equivalents: NFS can't represent negative available disk space ( Without the knowledge of the underlying filesystem on the server, negative free space is a little nonsensical anyway, I suppose) The attached patch stops the NFS server assigning negative values to unsigned fields in the statfs response, and works against my local solaris box. Seem reasonable? The client attampts to fix this by pretending that the unsigned fields are signed. -current tries to do more to support file system sizes larger that 1TB, but the code for this is not even wrong except it may be wrong enough to break the negative values. See my reply to one of the PRs for more details. I just got around to testing the patch in that reply: %%% Index: nfs_vfsops.c === RCS file: /home/ncvs/src/sys/nfsclient/nfs_vfsops.c,v Your patch to nfs_vfsops won't apply to my Solaris kernel :-) The protocol says abytes is unsigned, so the server shouldn't be lying by sending a huge positive value for available space on a full filesystem. No? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
On Fri, 14 Nov 2003, Peter Edwards wrote:
Bruce Evans wrote:
On Fri, 14 Nov 2003, Peter Edwards wrote:
The NFS protocols have unsigned fields where statfs has signed
equivalents: NFS can't represent negative available disk space ( Without
the knowledge of the underlying filesystem on the server, negative free
space is a little nonsensical anyway, I suppose)
The attached patch stops the NFS server assigning negative values to
unsigned fields in the statfs response, and works against my local
solaris box. Seem reasonable?
The client attampts to fix this by pretending that the unsigned fields
are signed. -current tries to do more to support file system sizes larger
that 1TB, but the code for this is not even wrong except it may be wrong
enough to break the negative values. See my reply to one of the PRs
for more details.
I just got around to testing the patch in that reply:
...
Your patch to nfs_vfsops won't apply to my Solaris kernel :-)
The protocol says abytes is unsigned, so the server shouldn't be lying
by sending a huge positive value for available space on a full
filesystem. No?
Possibly not, but the protocol is broken if it actually requires that.
The free fields are signed in struct statfs so that they can be negative.
However, this is broken in POSIX's struct statvfs (all count fields have
type fsblkcnt_t or fsfilcnt_t and these are specified to be unsigned).
Is Solaris bug for bug compatible with that?
Anyway, my patch is mainly supposed to fix the scaling. The main bug
in the initial scaling patch was that the huge positive values were
scaled before they were interpreted as negative values, so they became
not so huge but still preposterous values that could not be interpreted
as negative values.
The type pun to negative values is in most versions of BSD:
RELENG_4:
u_quad_t tquad;
...
if (v3) {
sbp-f_bsize = NFS_FABLKSIZE;
tquad = fxdr_hyper(sfp-sf_tbytes);
sbp-f_blocks = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE));
tquad = fxdr_hyper(sfp-sf_fbytes);
sbp-f_bfree = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE));
tquad = fxdr_hyper(sfp-sf_abytes);
sbp-f_bavail = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE));
sbp-f_files = (fxdr_unsigned(int32_t,
sfp-sf_tfiles.nfsuquad[1]) 0x7fff);
sbp-f_ffree = (fxdr_unsigned(int32_t,
sfp-sf_ffiles.nfsuquad[1]) 0x7fff);
} else {
sbp-f_bsize = fxdr_unsigned(int32_t, sfp-sf_bsize);
sbp-f_blocks = fxdr_unsigned(int32_t, sfp-sf_blocks);
sbp-f_bfree = fxdr_unsigned(int32_t, sfp-sf_bfree);
sbp-f_bavail = fxdr_unsigned(int32_t, sfp-sf_bavail);
sbp-f_files = 0;
sbp-f_ffree = 0;
}
Oops, this has the cast to long perfectly misplaced so that negative
sizes are not converted like I want. It just prevents warnings.
Overflow has occurred long before, on the server when negative block
counts were converted to hug positive sizes.
NetBSD (nfs_vfsops.c 1.132):
u_quad_t tquad;
...
...
if (v3) {
sbp-f_bsize = NFS_FABLKSIZE;
tquad = fxdr_hyper(sfp-sf_tbytes);
sbp-f_blocks = (long)((quad_t)tquad / (quad_t)NFS_FABLKSIZE);
tquad = fxdr_hyper(sfp-sf_fbytes);
sbp-f_bfree = (long)((quad_t)tquad / (quad_t)NFS_FABLKSIZE);
tquad = fxdr_hyper(sfp-sf_abytes);
sbp-f_bavail = (long)((quad_t)tquad / (quad_t)NFS_FABLKSIZE);
tquad = fxdr_hyper(sfp-sf_tfiles);
sbp-f_files = (long)tquad;
tquad = fxdr_hyper(sfp-sf_ffiles);
sbp-f_ffree = (long)tquad;
} else {
sbp-f_bsize = fxdr_unsigned(int32_t, sfp-sf_bsize);
sbp-f_blocks = fxdr_unsigned(int32_t, sfp-sf_blocks);
sbp-f_bfree = fxdr_unsigned(int32_t, sfp-sf_bfree);
sbp-f_bavail = fxdr_unsigned(int32_t, sfp-sf_bavail);
sbp-f_files = 0;
sbp-f_ffree = 0;
}
This converts tquad to quad_t so that the divisions work like I want. These
conversions were added in rev.1.82 in 1999.
More changes are needed here to catch up with the recent changes to struct
statfs in FreeBSD. The casts to long are now just wrong since the block
count fields don't have type long.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
On Fri, 14 Nov 2003, Peter Edwards wrote: Bruce Evans wrote: On Fri, 14 Nov 2003, Peter Edwards wrote: The NFS protocols have unsigned fields where statfs has signed equivalents: NFS can't represent negative available disk space ( Without the knowledge of the underlying filesystem on the server, negative free space is a little nonsensical anyway, I suppose) The attached patch stops the NFS server assigning negative values to unsigned fields in the statfs response, and works against my local solaris box. Seem reasonable? The client attampts to fix this by pretending that the unsigned fields are signed. -current tries to do more to support file system sizes larger that 1TB, but the code for this is not even wrong except it may be wrong enough to break the negative values. See my reply to one of the PRs for more details. I just got around to testing the patch in that reply: ... Your patch to nfs_vfsops won't apply to my Solaris kernel :-) The protocol says abytes is unsigned, so the server shouldn't be lying by sending a huge positive value for available space on a full filesystem. No? Possibly not, but the protocol is broken if it actually requires that. What makes you say that? I would think the utility of negative counts for disk sizes and available spaces is marginal. Solaris, POSIX, and NFS seem to get on fine without it. What am I (and they) missing? The free fields are signed in struct statfs so that they can be negative. However, this is broken in POSIX's struct statvfs (all count fields have type fsblkcnt_t or fsfilcnt_t and these are specified to be unsigned). Is Solaris bug for bug compatible with that? I'm away from any solaris boxes at the moment, but I know that df certainly reports huge free space when it sees the high bit set in the asize attribute of the NFS response. I'm not sure that this is directly relevant to NFS, though. Whatever the operating system's representation of FSSTATres is little to do with proper implementation of the protocol. I've no idea what Win32 represents this data in, but I'm sure it's very different from statv?fs. It'll provide and consume NFS services, though. Anyway, my patch is mainly supposed to fix the scaling. The main bug in the initial scaling patch was that the huge positive values were scaled before they were interpreted as negative values, so they became not so huge but still preposterous values that could not be interpreted as negative values. Ok, Understood. The type pun to negative values is in most versions of BSD: [snip code snippets and bug] That's great for interacting with other BSDs, but it still abusing the protocol. As filesystems with approaching 2^64 bytes become possible it probably has more of an impact. I understand that this is proably not a big enough problem to break historic behaviour for, of course. More changes are needed here to catch up with the recent changes to struct statfs in FreeBSD. The casts to long are now just wrong since the block count fields don't have type long. Sure. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it possible that rot13:/mnt2 has negative free space? (ie it's into the 8-10% reserved area). Kris Now accepting payment for data hosting Kennaway Have you tried writing a couple of GB to the NFS filesystem? Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who needs these silly statfs changes...
On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it possible that rot13:/mnt2 has negative free space? (ie it's into the 8-10% reserved area). Yes, that's precisely what it is..the bug is either in df or the kernel (I suspect the latter, i.e. something in the nfs code). Kris pgp0.pgp Description: PGP signature
Re: Who needs these silly statfs changes...
On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote: On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it possible that rot13:/mnt2 has negative free space? (ie it's into the 8-10% reserved area). Yes, that's precisely what it is..the bug is either in df or the kernel (I suspect the latter, i.e. something in the nfs code). And it's nothing new - I'm seeing this since several years now. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Who needs these silly statfs changes...
...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0a 205434 123332 6566865%/ devfs 11 0 100%/dev /dev/da0e 7957764 713336818777697%/usr rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2 Kris Now accepting payment for data hosting Kennaway pgp0.pgp Description: PGP signature
