Thread View: vmsnet.internals
2 messages
2 total messages
Started by SYSMGR
Thu, 05 Nov 1992 15:06
odd XQP behaviour
Author: 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)
Re: odd XQP behaviour
Author: George J Perkins
Date: Tue, 17 Nov 1992 01:06
Date: Tue, 17 Nov 1992 01:06
24 lines
2068 bytes
2068 bytes
In article <27A00A05_000735D8.009632ACBE1AF5C0$195_1@UK.AC.KCL.PH.IPG>, SYSMGR@IPG.PH.KCL.AC.UK (Nigel Arnot) writes: >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. I have no opinion on the cause of this oddity, but wonder if the addition of an explicit "INITIALSIZE=mmm,EXTENDSIZE=nnn" to the Vax Fortran OPEN statement for the affected file might override it, reducing the need for a quota extension (or at least letting the poor user use the extra space for something other than a temporary scratch area). If even this doesn't help, the classification definitely becomes more "bug" than "feature". ----------------------------------------------------------------------- George J Perkins perkins@msupa.pa.msu.edu gjperkins@fnal.fnal.gov
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads