What, exactly, are stat.st_blocks, statfs.f_bsize?

The Grey Wolf greywolf at unisoft.UUCP
Tue Mar 5 11:14:15 AEST 1991


<1991Feb26.010146.27490 at athena.mit.edu> by jik at athena.mit.edu (Jonathan I. Kamens)
# 
#   And, on a historical note, what led to the decision to measure in terms of
# 512-byte blocks, and why do some sites measure in terms of 1k blocks instead?
#

512 bytes seems to be the usual size of a physical sector on a disk
(as I have discovered the hard way via the /stand/diag stuff for a sun).
System V used 512-byte blocks in their filesystems from <insert generic
deity here>-knows-when up until 1k and 8k blocks in filesystems were
available.  (8k, I suspect, was for filesystems chock full of data so that
it could be schlumped around with "reasonable" speed.)  And even after
that, the 512-byte block survived.

Of course, there's one in every crowd:  Our pyramid's filesystems have
16k blocks and 2k fragments, and the disk itself is tuned to 2k physical
block size.  Go figure.

The reasoning behind figuring in terms of 1k blocks (or appearing to,
in the case of "du") was probably mathematical.  It might not take a whole
lot of effort to double or half a number (especially if you make the machine
do it for you :-), but someone out there probably figured that Wouldn't
Life Be So Much Simpler If... and it went from there.

Someone out there probably has even more historical info than this.

It would break some things, but would anyone else out there find it useful
to have the stat structure contain the number of logical blocks and the
number of fragments, rather than/in addition to the number of physical
blocks?

Are fs_blocksize and fs_fragsize for a file system defined anywhere?
(probably somewhere in the superblock, but is there a system call to
return this information?  fsstat/statfs deal with the fundamental blocksize,
but they don't provide info about the fragment size.  Assuming 8:1
isn't always right.)

Is it just me or should more information about a filesystem be available?


# -- 
# Jonathan Kamens			              USnail:
# MIT Project Athena				11 Ashford Terrace
# jik at Athena.MIT.EDU				Allston, MA  02134
# Office: 617-253-8085			      Home: 617-782-0710


-- 
# The days of the computer priesthood are not over.
# May they never be.
# If it sounds selfish, consider how most companies stay in business.



More information about the Comp.unix.wizards mailing list