lkml.org 
[lkml]   [2000]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[PATCH] statfs
I think we should apply the following patch to include/linux/fs.h:

--- fs.h~ Wed Mar 22 23:59:23 2000
+++ fs.h Thu Mar 23 15:32:19 2000
@@ -751,8 +751,7 @@
return -ENODEV;
if (!sb->s_op || !sb->s_op->statfs)
return -ENOSYS;
- memset(buf, 0xff, sizeof(struct statfs));
- buf->f_blocks = 0; /* Darn GNU df... */
+ memset(buf, 0, sizeof(struct statfs));
return sb->s_op->statfs(sb, buf);
}

[pasted from another window - tabs will have become spaces]

Below a discussion. Executive summary:

We never had the -1, but it was added because it was in the man page.
The man page did not describe a Linux reality, but was copied
from a BSD 4.4 manpage.
But also under BSD 4.4 the manpage did not describe reality.
So, there is no reason at all to start using -1, and there
are many reasons to leave everything as it was.

(Moreover, this special assignment is too ugly.)

I have changed the Linux manpage to say that undefined fields
in this struct are zero. (This is also the BSD 4.4 truth.)

Andries

===============================================================
In 2.3.51 statfs was changed to initialize the statfs structure
to -1, where it used to be 0.
It seems the change was inspired by the man page, which says

Fields that are undefined for a particular file system
are set to -1.

This change caused complaints - df suddenly showed 4294967295
where it used to show 0 or nothing at all.

Andreas Schwab (who always is right) says

SUS2 does not define any special meaning for -1 in
struct statfs. Moreover, fsblkcnt_t and fsfilcnt_t
are required to be unsigned integers, thus -1 does not
really fit here.

[However, the fields mentioned are fields in struct statvfs,
not statfs, so this seems irrelevant, or relevant only to glibc.]

IMHO the change should be reverted,
and the manpage should be fixed.


The man page says about statfs "Conforming to 4.4BSD",
but that doesnt seem to be true at all. Looking at the 4.4BSD-Lite
source I see
------------------------------------------------------------------------------
#define MNAMELEN 90 /* length of buffer for returned name */
struct statfs {
short f_type; /* type of filesystem (see below) */
short f_flags; /* copy of mount flags */
long f_bsize; /* fundamental file system block size */
long f_iosize; /* optimal transfer block size */
long f_blocks; /* total data blocks in file system */
long f_bfree; /* free blocks in fs */
long f_bavail; /* free blocks avail to non-superuser */
long f_files; /* total file nodes in file system */
long f_ffree; /* free file nodes in fs */
fsid_t f_fsid; /* file system id */
long f_spare[9]; /* spare for later */
char f_mntonname[MNAMELEN]; /* directory on which mounted */
char f_mntfromname[MNAMELEN];/* mounted filesystem */
};
------------------------------------------------------------------------------
where Linux has
------------------------------------------------------------------------------
struct statfs {
long f_type;
long f_bsize; /* optimal transfer block size */
long f_blocks;
long f_bfree;
long f_bavail;
long f_files;
long f_ffree;
fsid_t f_fsid;
long f_namelen;
long f_spare[6];
};
------------------------------------------------------------------------------
(MIPS also has an unsupported f_frsize field; some architectures
have int instead of long).
Thus, the Linux statfs call returns an animal that is rather
different from the BSD one. Moreover, reading BSD 4.4Lite sources,
I see many places where irrelevant fields are set to zero, and
not a single place where -1 is used.
So: First of all POSIX or SUSv2 do not specify anything because
they have statvfs, not statfs. And for statvfs nothing is said
about the contents of the fields.
Secondly, we cannot follow BSD 4.4 because it uses an entirely
different structure. And if we nevertheless follow it, we should
probably use 0.
Finally, it is useful to stay compatible with Linux.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.033 / U:0.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site