home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / vmsnet / internal / 1550 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  2.7 KB
  1. Path: sparky!uunet!stanford.edu!agate!usenet.ins.cwru.edu!gatech!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!mvb.saic.com!macro32
  2. Newsgroups: vmsnet.internals
  3. Subject: odd XQP behaviour
  4. Message-ID: <27A00A05_000735D8.009632ACBE1AF5C0$195_1@UK.AC.KCL.PH.IPG>
  5. From: SYSMGR@IPG.PH.KCL.AC.UK
  6. Date: Thu,  5 NOV 92 16:06:43 BST
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 41
  10.  
  11. Some of you may have noticed my recent posting to info-vax about VMS failing
  12. to allocate a pagefile on a slightly fragmented disk, and what to do about
  13. it. For those who didn't, the problem was that SYSGEN CREATE was failing to
  14. allocate an 80000 block pagefile on a disk with around 200000 blocks free
  15. in fragments of size over 6000 blocks. What it was doing was building a
  16. file out of about four decent-sised fragments, and then filling the header
  17. with all sorts of mostly tiny fragments presumably out of the extent cache.
  18.  
  19. If you used sysgen ten times, creating the pagefile with size 8000, then
  20. extending it to 16000, 24000, ... 80000, then there were no problems and
  21. it allocated 19 extents all of a decent size. (Sys managers - REMEMBER THIS!!)
  22.  
  23. I have now found another funny: the same problem in reverse. A user ran
  24. a FORTRAN program that generates two output files: the first stays small,
  25. the second ends up at around 3000 blocks, both are opened 'NEW' (ie empty)
  26. and filled with sequential writes.
  27.  
  28. Recently he noticed that the first file had been allocated with an initial
  29. size of 6000+ blocks. This was about two-thirds of his available disk quota,
  30. and also would have doomed the job (after a couple of days' crunching) because
  31. the second file would have run out of quota to grow into. I gave him more
  32. quota to avoid this, and the first file got truncated to about 20 blocks
  33. when the job finished.  I have never seen anything like this before VMS 5.5.
  34.  
  35. Does anyone *know* whether these behaviours constitute a bug or a feature?
  36. (please, no *opinions*, that'll just waste bandwidth). Ideally, the question
  37. will be answerted by someone who has read the XQP listings!
  38.  
  39. In addition, are there any experts on file structures out there who can
  40. tell me whether there is any good reason why the XQP doesn't refuse to use
  41. extents whose size is totally wrong with respect to the size of the file
  42. being extended? In the first instance, it knows that the file wanted is
  43. 80000 blocks. In the second, there is presumably no size indication, or
  44. perhaps a default such as the volume default extension quantity, which is
  45. nowhere near 6000 blocks.
  46.  
  47.         Yours,
  48.                 Nigel Arnot
  49.  
  50.                 NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
  51.                 NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
  52.