Article View: vmsnet.internals
Article #407odd XQP behaviour
From: SYSMGR
Date: Thu, 05 Nov 1992 15:06
Date: Thu, 05 Nov 1992 15:06
41 lines
2837 bytes
2837 bytes
Some of you may have noticed my recent posting to info-vax about VMS failing
to allocate a pagefile on a slightly fragmented disk, and what to do about
it. For those who didn't, the problem was that SYSGEN CREATE was failing to
allocate an 80000 block pagefile on a disk with around 200000 blocks free
in fragments of size over 6000 blocks. What it was doing was building a
file out of about four decent-sised fragments, and then filling the header
with all sorts of mostly tiny fragments presumably out of the extent cache.
If you used sysgen ten times, creating the pagefile with size 8000, then
extending it to 16000, 24000, ... 80000, then there were no problems and
it allocated 19 extents all of a decent size. (Sys managers - REMEMBER THIS!!)
I have now found another funny: the same problem in reverse. A user ran
a FORTRAN program that generates two output files: the first stays small,
the second ends up at around 3000 blocks, both are opened 'NEW' (ie empty)
and filled with sequential writes.
Recently he noticed that the first file had been allocated with an initial
size of 6000+ blocks. This was about two-thirds of his available disk quota,
and also would have doomed the job (after a couple of days' crunching) because
the second file would have run out of quota to grow into. I gave him more
quota to avoid this, and the first file got truncated to about 20 blocks
when the job finished. I have never seen anything like this before VMS 5.5.
Does anyone *know* whether these behaviours constitute a bug or a feature?
(please, no *opinions*, that'll just waste bandwidth). Ideally, the question
will be answerted by someone who has read the XQP listings!
In addition, are there any experts on file structures out there who can
tell me whether there is any good reason why the XQP doesn't refuse to use
extents whose size is totally wrong with respect to the size of the file
being extended? In the first instance, it knows that the file wanted is
80000 blocks. In the second, there is presumably no size indication, or
perhaps a default such as the volume default extension quantity, which is
nowhere near 6000 blocks.
Yours,
Nigel Arnot
NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk (internet)
NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet (bitnet)
Technical Details
Message-ID:
<27A00A05_000735D8.009632ACBE1AF5C0$195_1@UK.AC.KCL.PH.IPG>Path:
arc1-ca.pugleaf.net!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!macro32Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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 Newsgroups: vmsnet.internals Subject: odd XQP behaviour Message-ID: <27A00A05_000735D8.009632ACBE1AF5C0$195_1@UK.AC.KCL.PH.IPG> From: SYSMGR@IPG.PH.KCL.AC.UK Date: Thu, 5 NOV 92 16:06:43 BST Organization: Macro32<==>Vmsnet.Internals Gateway X-Gateway-Source-Info: Mailing List Lines: 41