What, exactly, are stat.st_blocks, statfs.f_bsize?
Jonathan I. Kamens
jik at athena.mit.edu
Mon Mar 4 10:10:26 AEST 1991
In article <kre.668039321 at mundamutti.cs.mu.OZ.AU>, kre at cs.mu.OZ.AU (Robert Elz) writes:
|> st_blocks should be in units of the most elementary allocation amount
|> (which is typically disc sectors) - that's required for accuracy in the
|> count. Factors of that number are OK, but wasteful, multiples of it
|> (picking a "nice" number) are simply wrong. This is definitely a
|> system dependant number (and could be file system dependant).
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.
Now you say that in fact it's OK for different systems to use different
block sizes when calculating st_blocks.
What neither of you have said is how to *find out* the block size on any
particular system, or on any particular filesystem. That is the piece of
information I most need to know, because without it, I can't make my program
correctly report the actual amount of space taken up by files.
|> Programs reporting this number should probably convert it to a useful
|> standard unit in most cases, for this purpose it doesn't matter much
|> what that unit is - I believe POSIX chose units of 512 for most
|> applications, I would have thought 1K was more human friendly.
As I said in my original posting, the POSIX stat structure doesn't have
st_blocks, or at least it doesn't according to the POSIX book I looked in. So
what exactly are you talking about here?
I *want* my program to convert from st_blocks to k. I just don't know how
to do it, because I don't know how to reliably predict what st_blocks
represents. So, for now, I'm just ignoring it.
So, any suggestions?
--
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
More information about the Comp.unix.internals
mailing list