Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request
From: mondo!asgard@uunet.uu.net (Jay R. Stoner)
Newsgroups: comp.sys.sun
Subject: Re: Sun accounting data
Keywords: Miscellaneous
Message-ID: <2959@brazos.Rice.edu>
Date: 13 Nov 89 15:25:46 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 22
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n156, Replies: v8n159 v8n161 v8n177 v8n183 v8n190
X-Sun-Spots-Digest: Volume 8, Issue 194, message 5 of 23

In article <2880@brazos.Rice.edu> barmar@kulla.arpa (Barry Margolin):
;In article <2556@brazos.Rice.edu> stanonik@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.