home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sun / admin / 9435 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  4.9 KB
  1. Xref: sparky comp.sys.sun.admin:9435 comp.unix.admin:6641
  2. Path: sparky!uunet!dove!cam!fs3!klm
  3. From: klm@nist.gov (Ken_Manheimer_x3539)
  4. Newsgroups: comp.sys.sun.admin,comp.unix.admin
  5. Subject: Group-oriented disk-space apportionment schemes??
  6. Message-ID: <KLM.92Dec14175003@coil.nist.gov>
  7. Date: 14 Dec 92 22:50:03 GMT
  8. Sender: news@cam.nist.gov
  9. Distribution: comp
  10. Organization: National Institute of Standards and Technology
  11. Lines: 85
  12.  
  13. I'm looking for suggestions and experiences managing NFS disk
  14. apportionment across large user bases according to their memberships
  15. in organizational groups.
  16.  
  17. I'm designing a shared-filesystem service intended for wide sharing
  18. within my organization.  The primary aim of the service is to provide
  19. the capability for file sharing to those organizational divisions so
  20. small or non-technically oriented ("technically disoriented"?-) that
  21. they do not have their own facilities to provide this capability.
  22.  
  23. The amount of disk space is by no means large relative to the size of
  24. the prospective clientele, so we will have to be vigilant about disk
  25. allocations.  I envision having to have some nominal allocation, and
  26. then bump people up as they need more.  This individual-account based
  27. approach has a number of what i see as serious drawbacks.  They
  28. include, off the top of my head:
  29.  
  30.  - Large groups with lots of members can claim much larger portions,
  31.    but large groups are the ones most likely to not have great *need*
  32.    for the service.  They are more likely to have their own disk
  33.    service resources, and so already have the capability for disk
  34.    sharing which is the real aim of this service.  (Everyone always
  35.    could use *more* disk, but that's not what the service is for.  The
  36.    intent is to provide something to the have-nots that they need, not
  37.    supplement the disk space contingent of anyone who wants it.)
  38.  - Usage accounting is almost inevitably most useful when done
  39.    according to groups.  This is difficult, with the groups
  40.    allocations scattered all over the map, and the propriety of a file
  41.    sometimes (probably much more than occasionally) being the owner's
  42.    secondary groups, not their primary one.
  43.  - In general, individual-account based allocation means large
  44.    databases that are difficult if not unmanageable for mapping to
  45.    collective allocations.
  46.  
  47. I would *really* like to be able to allocate disk space portions to
  48. collective groups (possibly but not necessarily the formal Unix groups
  49. dictated by the /etc/group file), and have the space available to an
  50. individual depend on some group of the hierarchy.  I do not see a
  51. manageable way to do this, however.  The server will be a Sun machine
  52. running SunOS 4.1.3.  Quotas under SunOS (and any typical Unix OS, as
  53. far as i know) are purely account oriented,
  54.  
  55. I've thought about (ab)using other mechanisms, like disk partitioning,
  56. to divvy out space to collective groups, but
  57.  
  58.  (1) nothing i've come up with would provide the number of units i'd
  59.      need,
  60.  (2) even if some alternate could be finagled to arrange for enough
  61.      portions to go around, there are some real problems with such
  62.      mechanisms when it comes to boundary conditions (eg, exhaustion
  63.      of the space allocated to a group) and reallocation.
  64.  
  65. As i said, i've considered using disk partitioning to make the group
  66. apportionments.  Nominal individual accounts would be used in
  67. conjunction with the partitions to control the way the disk space is
  68. consumed.  However,
  69.  
  70.  - (1) Disk partitioning only enables dividing a disk into 7 portions,
  71.        as far as i know - [a-h], minus the 'c' partition, which must
  72.        encompass the whole disk.
  73.  - (2) The only way i can think of to expand the space available to a
  74.        group is by creating moving all their stuff to a new, bigger
  75.        partition elsewhere (or archiving their stuff, recreating their
  76.        partition with more space, and then replacing their stuff in
  77.        the larger space - not a fun process, considering the
  78.        drastically large chances for catastrophic screwups).
  79.  - (2) Users discover their group has run out of space when the disk
  80.        is (effectively) full, and the write fails.  (In some
  81.        situations the file would be left partially written, i think.
  82.        Yick.)
  83.  
  84. What the heck do other people do in this situation?  I wonder whether
  85. anyone has developed a preprocessor produces the quota data files
  86. according to higher-level group, disk-layout, and defaulting
  87. information.  Is there some approach i'm missing, or some prominent,
  88. alternate substrate (a mythical NFS++, or the commercial form of AFS),
  89. that takes on this issue directly and successfully??
  90.  
  91. Please respond to me via email - i find it almost impossible to keep
  92. up with these newsgroups - and i'll summarize what i uncover.
  93.  
  94. Ken Manheimer  klm@cam.nist.gov    Computer Systems and Computation Division
  95. W: 301 975-3539                    Nat'l Institute of Standards and Technology
  96. H: 301 762-4868                    Technology 225/A151
  97.                                    Gaithersburg, MD 20899
  98.