What, exactly, are stat.st_blocks, statfs.f_b
Sean Eric Fagan
sef at kithrup.COM
Mon Mar 4 11:54:51 AEST 1991
In article <1991Mar4.001026.3043 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
> OK, so how do you find out the number for a particular filesystem? We've
>seen one answer that says it should be in terms of 512-byte blocks on any
>systems, and that systems that use something other than 512-byte blocks are
>broken.
SysVr3.2 (kithrup, at least) has a system call called 'statfs'. It returns
lots of information about the filesystem, including:
struct statfs {
short f_fstyp; /* File system type */
long f_bsize; /* Block size */
long f_frsize; /* Fragment size (if supported) */
long f_blocks; /* Total number of blocks on file system */
long f_bfree; /* Total number of free blocks */
long f_files; /* Total number of file nodes (inodes) */
long f_ffree; /* Total number of free file nodes */
char f_fname[6]; /* Volume name */
char f_fpack[6]; /* Pack name */
};
If the 3.2 stat() returned st_blocks, then it would take two system calls to
find out the desired information. (Side note: in SCO's implementation,
pathconf and fpathconf are based on statfs(). It's a neat system call. 8-))
> Now you say that in fact it's OK for different systems to use different
>block sizes when calculating st_blocks.
Yep. The fact that there is no way in SunOS (prior to 4.0 or 4.1, since
those are supposed to be SysVr4 compatible, which is SysVr3.2 compatible,
meaning it should have the statfs() call) or BSD to get the information is a
defect in the OS. However, it should be relatively easy to fix.
*If* POSIX ever decides to add the st_blocks feature (which might or might
not be a good thing; I've not decided yet), then I would hope it would also
adds something similar to the statfs() call...
--
Sean Eric Fagan | "I made the universe, but please don't blame me for it;
sef at kithrup.COM | I had a bellyache at the time."
-----------------+ -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.
More information about the Comp.unix.internals
mailing list