Messages in this thread Patch in this message | | | Date | Thu, 23 Mar 2000 16:14:38 +0100 (MET) | From | Andries.Brouwer@cwi ... | 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/
| |