From guy@auspex.auspex.com Sun Jul 15 23:01:44 1990 From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: what are st_blksize and st_blocks exactly? Date: 15 Jul 90 00:29:53 GMT Distribution: na Organization: Auspex Systems, Santa Clara >The stat(2) documentation for SunOS 4.0.3 says: > > long st_blksize; /* preferred blocksize for file system I/O*/ > long st_blocks; /* actual number of blocks allocated */ And the 4.3-tahoe documentation - those two fields originally appeared in 4.2BSD (well, maybe 4.1c or something if you want to be *really* picky) - says: long st_blksize; /* optimal blocksize for file system i/o ops */ long st_blocks; /* actual number of blocks allocated */ which isn't any better. >It doesn't mention what units st_blocks is measured in, but those >units don't look like they're the value of st_blksize. >How are these two fields related, if at all? >Is st_blocks always measured in 512 byte units, or is there a value >somewhere that indicates the block size for it? The answer is "st_blocks is measured in 512-byte units, at least on systems with a DEV_BSIZE of 512 - this includes all Suns, and VAXes, and probably most other systems - or running System V Release 4." The System V Release 4 documentation could either be considered worse than, or better than, the BSD/S5 documentation in this regard. Better, because it does say what the units are. Worse, because it says it in both the comment on the "st_blocks" field in the list of fields *and* in the description of the field, and the two descriptions disagree with one another! The correct description is almost certainly the one in the description of the field: st_blocks The total number of physical blocks of size 512 bytes actually allocated on disk. because that's what it is in 4.[23]BSD, SunOS, and probably all the systems that picked it up from 4.[23]BSD. The description in the comment in the S5R4 manual page says it's in units of "st_blksize", which makes no sense - "st_blksize" is the optimal size for I/O, and in UFS (4.[23]BSD) file systems is typically larger (by factors of 8 or more) than the allocation quantum for disk blocks in the file system. As I remember, the AT&T folk originally thought that "st_blocks" was supposed to be in units of "st_blksize", but were convinced otherwise; the comments in the code may not have been fixed in time to get the fix into the man page, but the actual description of the field was fixed in time. The Third Edition of the SVID has the same confusion; I hope the SVVS makes sure that the number of 512-byte blocks is returned (even if the disk has 1024-byte sectors; just return twice the number of those sectors). Still, it's better than the S5R4 Migration Guide claiming that "To allow binary compatibility with Release 2 programs, the Relase 4.0 'stat' structure is identical to the Release 3.2 'stat' structure. BSD programs requiring the two additional fields need to be relinked with a compatibility library." That statement contradicts the SVID (which lists the two fields, "st_blocks" and "st_blksize"), the S5R4 documentation (which lists those two fields), and the experience of people who did 4.2BSD (4.2BSD changed the system call number for "stat", and had an option to let the old system call number return the old "stat" structure, for binary compatibility with 4.1BSD, which used the V7 structure that S5-prior-to-R4 used). From torek@elf.ee.lbl.gov Tue Feb 26 00:08:34 1991 From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: What, exactly, are stat.st_blocks, statfs.f_bsize? Date: 26 Feb 91 00:05:33 GMT Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley X-Local-Date: Mon, 25 Feb 91 16:05:34 PST In article <1991Feb25.205932.16587@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >... on a 4.3BSD system, the stat structure contains the st_blocks field, >which tells the "actual number of blocks allocated." Given that >description, the question becomes, what exactly is a "block?" There are two >possible answers: > >1. The size specified by DEV_BSIZE. >2. The size in the f_bsize field of the statfs structure of the filesystem on > which the file resides. The answer is `none of the above'. >Now, it seemed to me that f_bsize would be the logical choice, No: f_bsize is the `block' size and not the `fragment' size under 4.3BSD-reno, i.e., typically 8K rather than 1K. (SunOS and 4BSD are different here; SunOS defines f_bsize as the fragment size.) >The 4.3reno stat(2) man page goes even further; it describes st_blocks >as "The actual number of blocks allocated for the file in 512-byte units." >But that leaves me with another question -- is it DEV_BSIZE, or 512 bytes? It is 512 bytes; it does not matter what DEV_BSIZE is. Under 4.3tahoe on the Tahoe, DEV_BSIZE was 1024; 4.3reno has no DEV_BSIZE at all (well, it has one as a compatibility hack) and each disk's block size is a property of that disk. Note that there may be (probably are) some systems out there in which st_blocks is in terms of 1 kbyte blocks; these should dwindle away, but will probably leave a lingering stench. :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov From guy@auspex.auspex.com Tue Mar 5 05:34:43 1991 From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.internals Subject: Re: What, exactly, are stat.st_blocks, statfs.f_b Date: 5 Mar 91 09:10:35 GMT Organization: Auspex Systems, Santa Clara >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, Umm, no, they're not. Some Sun Marketoons may have claimed, without proper qualification, that they're completely compatible; they're pretty close, but they're *not* completely compatible. SunOS 4.x has the same "statfs()" call that SunOS releases prior to 4.x did. >which is SysVr3.2 compatible, meaning it should have the statfs() call) S5R4 does, I presume, have the same "statfs()" call as S5R3; however the call you're *supposed* to use in S5R4 is "statvfs()", which is a new call in S5R4, atoning for S5R3's error in having a "statfs()" call with the same name as SunOS's but incompatible semantics. You don't need to use that call to find out the units of "st_blocks", though; the S5R4 manual states that "st_blocks" is "the total number of physical blocks of size 512 bytes actually allocated on disk." Presumably, if the allocation granularity of the disk, or of the file system, is in blocks that are some multiple of 512 bytes in size, the number-of-blocks will be multiplied by that multiple to get the number of 512-byte chunks. If it's the units are less than 512 bytes, the system'd have to *divide* by the ratio of sizes, and if the ratio of sizes isn't integral, you'd have a problem; fortunately, I suspect most UNIX systems have disks whose sector size is some multiple of 512 bytes (the only exceptions may be assorted mainframes, such as IBM mainframes, although the UNIXes on those systems may, when not working on fixed-block-size disks, use some standard block size - I don't think anybody's ported UNIX to the IBM 1130, so that doesn't count... :-)). The SunOS documentation doesn't say what the units are, but "st_blocks" is in units of 512 bytes on UFS and on NFS to most if not all UNIX servers, and should be in units of 512 bytes on any other file systems plugged into your system. The NFS protocol spec does not, alas, do a very good job of explaining the fields of the "fattr" structure, so it's conceivable that a server writer may not return a file size in 512-byte units in the "blocks" field. It *should* have indicated that the "blocksize" field is the block size *recommended for I/O*, rather than the block size used as units for the "blocks" field, as the "blocksize" field is what gets turned into the "st_blksize" field, and that field - in BSD, in SunOS, and in S5R4 - is the recommended block size for I/O operations. It should also have indicated that the "blocks" field should be in units of 512 bytes. As for "statfs()" a la SunOS, "statfs()" a la S5R3, and "statvfs()" a la S5R4 (including, I assume, Sun's current "developer's release" of S5R4, and any future Sun releases of S5R4): SunOS "struct statfs" includes: long f_bsize; /* fundamental file system block size */ long f_blocks; /* total blocks in file system */ long f_bfree; /* free blocks */ long f_bavail; /* free blocks available to non-super-user */ where "f_bsize" is the unit of allocation of the particular file system - i.e., on a BSD/UFS file system, the "fragment size", which may be bigger than the sector size; it's typically 1K on Sun systems, even though the sector size is 512 bytes. "st_bfree" and "st_bavail" are in units of "f_bsize", not units of 512 bytes. (Determined by checking the code; it's not well-documented.) S5R3's "struct statfs" includes: 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 */ where "f_bsize" is, on S5 file systems, the unit of allocation of the particular file system - i.e., on a 1K file system, it's 1K, and on a 512-byte file system, it's 512 bytes. "f_frsize" is 0. (All as of S5R3.1, from checking the code.) Dunno what's done on S5 systems that support a BSD file system; one presumes the idea is that "fs_bsize" is the "block size", and "fs_fsize" is the "fragment size", the *latter* being the true unit of allocation, and the former being more the suggested unit of I/O. "f_blocks" and "f_bfree" are in units of 512-byte chunks. S5R4's "struct statvfs" includes: ulong f_bsize; /* preferred file system block size */ ulong f_frsize; /* fundamental filesystem block size (if supported) */ ulong f_blocks; /* total # of blocks on file system in units of f_frsize */ ulong f_bfree; /* total # of free blocks */ ulong f_bavail; /* # of free blocks avail to non-superuser */ I'm not sure what this "(if supported)" nonsense is for "f_frsize"; if it's not "supported", the "f_blocks" and, presumably, "f_bfree" and "f_bavail" fields are meaningless, as the former is documented as being in units of "f_frsize" and the other two are, I assume, also in those units. I suspect that, for an S5 file system, both "f_bsize" and "f_frsize" are supported; dunno whether the latter is 512 or the block size of the file system. Dunno whether "f_bsize" is the block size of the file system, or 512, or 1024, or what. For a BSD/UFS file system, "f_bsize" is probably the block size (recommended I/O size) and "f_frsize" is probably the fragment size (unit of allocation). (Determined from reading the documentation.)