heiser@sud509.ray.com ( Sun Workstation Support) (10/07/89)
When I do an 'sa -m' to list accounting stats for each user, I see the following line appear twice: preposterous userid 65534; blah blah blah Any idea where this comes from and/or how to get rid of it? Thanks in advance, Bill Heiser Work: heiser@sud524.ray.com Home: Bill.Heiser@f101.n324.z1.fidonet.org (Fidonet 1:324/101) Other: 75106.2332@compuserve.com
emv@math.lsa.umich.edu (10/11/89)
65534 == -2 (mod 2^16) -- it's the uid that corresponds to 'nobody'. I'd use 'grep -v' to get rid of it. --Ed Edward Vielmetti, U of Michigan math dept.
knutson@perseus.sw.MCC.COM (Jim Knutson) (10/13/89)
You must have fixed the rwall bug so that rwall now runs as nobody. The nobody UID (signed -2) is equivalent to unsigned uid 65534. The fix we are using is to define a login with uid 65534. The nobody uid will be dissapearing soon and will be replaced by a large number soon (so says Sun). Jim Knutson knutson@mcc.com cs.utexas.edu!milano!knutson
barmar@kulla.arpa (Barry Margolin) (11/01/89)
In article <2556@brazos.Rice.edu> stanonik@nprdc.navy.mil (Ron Stanonik) writes: >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. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
knutson%perseus.sw.MCC.COM@mcc.com (Jim Knutson) (11/02/89)
The size may look that large, but that actual file will have holes in it where no uid exists. On our system, that file is only 64K of data blocks, but 1.8MB in size. Jim Knutson knutson@mcc.com cs.utexas.edu!milano!knutson
asgard@uunet.uu.net (Jay R. Stoner) (11/13/89)
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.