home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / sysmgt / 228 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.3 KB  |  81 lines
  1. Newsgroups: vmsnet.sysmgt
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ncar!uchinews!iitmax!draughn
  3. From: draughn@iitmax.iit.edu (Mark Draughn)
  4. Subject: Need Help With Disk Rebuild Problem.
  5. Message-ID: <1992Jul30.004447.1273@iitmax.iit.edu>
  6. Organization: Illinois Institute of Technology
  7. Date: Thu, 30 Jul 92 00:44:47 GMT
  8. Lines: 71
  9.  
  10. I'm having a system performance problem that I hope someone can help
  11. me with.
  12.  
  13. We're running VMS 5.4-2.
  14.  
  15. We have about 9000 users on our VAX cluster.  All of the user
  16. directories are on one volume set containing about 200000 files using
  17. 2.5 GB, which is served to the cluster.
  18.  
  19. THE PROBLEM:  After a crash, when the volume set is mounted, the
  20. automatic rebuild takes about an hour.  This is a major pain.
  21.  
  22. I've got things set up so that this volume is only rebuilt if the
  23. server crashes.  If one of the satellites crashs, we live with the
  24. corruption.  This is still a problem because a server crash will hang
  25. all user file activity for an hour during the rebuild.  Even a simple
  26. shutdown-and-reboot cycle on the server can take an hour if any of the
  27. systems in the cluster has crashed since the last reboot.
  28.  
  29. SOME SPECULATION:
  30.  
  31. A little experimentation suggests that the basic disk rebuild is fast,
  32. but that updating disk quotas is very slow.  I think this is because
  33. disk quota entries are cached but not sorted or indexed.
  34.  
  35. The quota rebuild process uses the ACP-QIO interface to rebuild the
  36. quota file.  Each time it updates a quota entry, the ACP (actually the
  37. XQP) has to do a sequential search for the right record.  Since all
  38. quota entries are being accessed, the caching doesn't help.  The
  39. result is that the quota rebuilding process is quadratic in the number
  40. of quota entries.
  41.  
  42. Just for the heck of it, I wrote a program that scans the INDEXF.SYS
  43. files and gathers all the quota information, then rewrites the quota
  44. file directly.
  45.  
  46. The good news is that it only takes 5 minutes.
  47.  
  48. The bad news is that the quota cache is not invalidated when the quota
  49. file is opened.  I can't even update the cached entries using the
  50. ACP-QIO interface because I don't know which UICs are cached.  The
  51. only way I know to invalidate the cache is to disable quotas then
  52. re-enable them.  However, in order to preserve the accuracy of the
  53. disk quota usage information (which is, after all, the purpose of
  54. rebuilding the quota file) this has to be done on all nodes while the
  55. volume set is locked.  The ACP Control function FIB$C_DSA_QUOTA only
  56. works on the current node---other nodes in the cluster will still have
  57. quotas enabled.  (I suppose I could make it work by starting DECNET
  58. servers on the other nodes to do the disk quota operations, but this
  59. seems excessive.
  60.  
  61. ----------
  62.  
  63. So.  Does anybody else have this slow rebuild problem?  How do you
  64. deal with it?  I can't believe we're the only site with thousands of
  65. disk quota entries on one volume set.
  66.  
  67. I would love to be told that I'm ignorant of an obvious solution.
  68. (Disabling quotas, reducing the number of users, breaking up the
  69. volume set, or rebuilding off-line are not possible.)  Does DEC plan
  70. to fix this performance problem?  Better yet, has DEC fixed this in
  71. VMS 5.5?
  72.  
  73. Any suggestions?
  74.  
  75. Thanks.
  76. -- 
  77.  
  78. Mark Draughn    | <draughn@iitmax.iit.edu> or <SYSMARK@IITVAX> on BITNET
  79. ----------------+ Academic Computing Center, Illinois Institute of Technology
  80. +1 312 567 5962 | 10 W. 31st Street, Chicago, Illinois  60616
  81.