From: klm@nist.gov (Ken_Manheimer_x3539)
Newsgroups: comp.sys.sun.admin,comp.unix.admin
Subject: Group-oriented disk-space apportionment schemes??
Date: 14 Dec 92 22:50:03 GMT
Distribution: comp
Organization: National Institute of Standards and Technology

I'm looking for suggestions and experiences managing NFS disk
apportionment across large user bases according to their memberships
in organizational groups.

I'm designing a shared-filesystem service intended for wide sharing
within my organization.  The primary aim of the service is to provide
the capability for file sharing to those organizational divisions so
small or non-technically oriented ("technically disoriented"?-) that
they do not have their own facilities to provide this capability.

The amount of disk space is by no means large relative to the size of
the prospective clientele, so we will have to be vigilant about disk
allocations.  I envision having to have some nominal allocation, and
then bump people up as they need more.  This individual-account based
approach has a number of what i see as serious drawbacks.  They
include, off the top of my head:

 - Large groups with lots of members can claim much larger portions,
   but large groups are the ones most likely to not have great *need*
   for the service.  They are more likely to have their own disk
   service resources, and so already have the capability for disk
   sharing which is the real aim of this service.  (Everyone always
   could use *more* disk, but that's not what the service is for.  The
   intent is to provide something to the have-nots that they need, not
   supplement the disk space contingent of anyone who wants it.)
 - Usage accounting is almost inevitably most useful when done
   according to groups.  This is difficult, with the groups
   allocations scattered all over the map, and the propriety of a file
   sometimes (probably much more than occasionally) being the owner's
   secondary groups, not their primary one.
 - In general, individual-account based allocation means large
   databases that are difficult if not unmanageable for mapping to
   collective allocations.

I would *really* like to be able to allocate disk space portions to
collective groups (possibly but not necessarily the formal Unix groups
dictated by the /etc/group file), and have the space available to an
individual depend on some group of the hierarchy.  I do not see a
manageable way to do this, however.  The server will be a Sun machine
running SunOS 4.1.3.  Quotas under SunOS (and any typical Unix OS, as
far as i know) are purely account oriented,

I've thought about (ab)using other mechanisms, like disk partitioning,
to divvy out space to collective groups, but

 (1) nothing i've come up with would provide the number of units i'd
     need,
 (2) even if some alternate could be finagled to arrange for enough
     portions to go around, there are some real problems with such
     mechanisms when it comes to boundary conditions (eg, exhaustion
     of the space allocated to a group) and reallocation.

As i said, i've considered using disk partitioning to make the group
apportionments.  Nominal individual accounts would be used in
conjunction with the partitions to control the way the disk space is
consumed.  However,

 - (1) Disk partitioning only enables dividing a disk into 7 portions,
       as far as i know - [a-h], minus the 'c' partition, which must
       encompass the whole disk.
 - (2) The only way i can think of to expand the space available to a
       group is by creating moving all their stuff to a new, bigger
       partition elsewhere (or archiving their stuff, recreating their
       partition with more space, and then replacing their stuff in
       the larger space - not a fun process, considering the
       drastically large chances for catastrophic screwups).
 - (2) Users discover their group has run out of space when the disk
       is (effectively) full, and the write fails.  (In some
       situations the file would be left partially written, i think.
       Yick.)

What the heck do other people do in this situation?  I wonder whether
anyone has developed a preprocessor produces the quota data files
according to higher-level group, disk-layout, and defaulting
information.  Is there some approach i'm missing, or some prominent,
alternate substrate (a mythical NFS++, or the commercial form of AFS),
that takes on this issue directly and successfully??

Please respond to me via email - i find it almost impossible to keep
up with these newsgroups - and i'll summarize what i uncover.

Ken Manheimer  klm@cam.nist.gov    Computer Systems and Computation Division
W: 301 975-3539                    Nat'l Institute of Standards and Technology
H: 301 762-4868                    Technology 225/A151
                                   Gaithersburg, MD 20899