Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!unisoft!greywolf From: greywolf@unisoft.UUCP (The Grey Wolf) Newsgroups: comp.unix.wizards Subject: Re: What, exactly, are stat.st_blocks, statfs.f_bsize? Message-ID: <3413@unisoft.UUCP> Date: 5 Mar 91 01:14:15 GMT References: <1991Feb25.205932.16587@athena.mit.edu> <10283@dog.ee.lbl.gov> <1991Feb26.010146.27490@athena.mit.edu> Reply-To: greywolf@unisoft.UUCP (The Grey Wolf) Organization: Foo Bar and Grill Lines: 51 <1991Feb26.010146.27490@athena.mit.edu> by jik@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 -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@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.