🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: vmsnet.internals
2 messages
2 total messages Started by SYSMGR Thu, 05 Nov 1992 15:06
odd XQP behaviour
#407
Author: SYSMGR
Date: Thu, 05 Nov 1992 15:06
41 lines
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
#444
Author: George J Perkins
Date: Tue, 17 Nov 1992 01:06
24 lines
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