Sun accounting data

[Jay R. Stoner]

In article <2880 at brazos.Rice.edu> barmar at kulla.arpa (Barry Margolin):
;In article <2556 at brazos.Rice.edu> stanonik at nprdc.navy.mil (Ron Stanonik):
;>I'd prefer to see nobody assigned a real small uid.  /usr/adm/usracct size
;>is 32*maxuid, which is about 2Mb for uid 65534.  Most of that 2Mb is
;>wasted unless you have ~64k users.

;But most of that space would be empty.  Unix doesn't actually store file
;blocks that are all zero.  So, the disk space allocated for the usracct
;file would only be increased by at most one block.

More correctly, the inode blocklist will have large areas of UFS_HOLE
instead of valid block pointers, with one or more of the indirect block
pointers in the inode also being UFS_HOLE.

If we have as an example, a file which was created, lseeked to 2Mb, and
then have one block written, the i_size field of the inode will reflect
the allocation of 2Mb+8K.  The i_nblocks field will really be 2 and not
1025, as you might expect.  This reflects the block pointed by the singly
indirect block and the data block pointed within the indirect block.  The
disk usage of a file is represented by the i_nblocks field and not i_size.
If you do any writes into an area of a file with UFS_HOLE it is replaced
by an allocated block and the counts updated.