[Info-vax] 8.4 freespace-drift problem?

[Stephen Hoffman]

On 2015-05-22 02:40:45 +0000, David Froble said:

> Phillip Helbig (undress to reply) wrote:
>> Twice since the upgrade I've noticed that the free space was off by 
>> about 4 GB.  (After the upgrade I went from 4-GB to 9-GB disks, which 
>> gave me 5 GB free instead of 1.  I was really surprised when I saw just 
>> 1 GB free.)  ANA/DISK/REPAIR fixes it, but it appeared again a day 
>> later.
>> 
>> Has anyone else seen this?
>> 
>> In the last 20 years or so I have never seen this much freespace drift 
>> on my hobbyist systems.
>> 
>> The problem (at least so far) has been only on the system disk with 8.4.

Phillip: Upgrade the entire cluster to V8.4.  You're troubleshooting a 
fairly long span of software versions in a cluster, you've probably had 
some hard halts and some crashes, and you're working with a number of 
badly under-patched V7.3-2 systems.  Your hardware is also not really 
suited to what you're trying to do, too.   Why upgrade everything?   
Your V8.4 patches are much newer than much of what you're running on 
here, and it may well be the V7.3-2 boxes or potentially some quirk of 
local operations here — crashes and hard halts are the most common 
causes of free space drift, in my experience — and not the V8.4 box 
that's centrally causing the drift.

Phillip: FWIW, you're also running ancient Alpha hardware with what are 
now exceedingly small disks and probably with equivalently-constrained 
physical memory, but then this is your museum of Y2K computing, and not 
mine.  An Alpha emulator will very likely be a substantial storage 
capacity upgrade, and may well be a memory and performance upgrade from 
the hardware configuration that you're using here, after all.   Fifteen 
or twenty year old gear has capacity and performance limits beyond its 
basic operation, after all.  Emulation at least gets you clear of the 
pre-EV6 gear you're using.

> Why am I so happy that I'm still running V8.3 ????

David: V8.4 with mid- to current-vintage patches works here, and works 
at the sites I'm dealing with, including with DECwindows on an 
EV6-compatible graphics controller.  But then I'm not (intentionally) 
not running a whole lot of 100 MbE hosts and definitely not running 
HBVS across a 100 MbE network connection — that full copy would take a 
whole lot longer with the 146 GB disks and the larger disks that are 
more typical than what Phillip is running.  Multi-host SCSI or FC would 
be typical for such a configuration, when that's necessary.

Both: Unfortunately, OpenVMS free space drift has been around for eons, 
and there's been ongoing work to reduce it.  But it's a cached value, 
and there are known cases where the value can and will drift.  Hard 
crashes and hard halts being two of the most common triggers — if some 
host is working with the disk and is holding the disk lock and performs 
various deletions which update the free space and then that host 
suddenly goes bye-bye hard, you will get free space drift.  At least 
until the next rebuild is performed.

Phillip: When it is convenient, invoke SET VOLUME /REBUILD=FORCE and 
the lock value block free space value will be resynchronized with the 
disk storage.



-- 
Pure Personal Opinion | HoffmanLabs LLC