[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[Stephen Hoffman]

On 2016-06-17 22:28:50 +0000, lawrencedo99 at gmail.com said:

> On Saturday, June 18, 2016 at 2:26:45 AM UTC+12, Stephen Hoffman wrote:
> 
>> The OpenVMS ODS-2 and ODS-5 file systems uses careful write ordering, 
>> which means it typically doesn't lose data in the event of a partial or 
>> complete power failure or system crash, and doesn't corrupt itself.
> 
> Then where is the inconsistency in free-space usage coming from? You 
> know, the issue that started this thread?

Caching.  The displayed value is stored in a lock value block and — 
bugs aside, and there have been bugs here — the value that's cached in 
that lock value block can be lost when a host crashes.  That causes a 
skew.  Accessing that free space data from disk is slow, the accuracy 
of that value was not considered a requirement, and hence it's cached 
in memory; in a lock value block.

The volume rebuild operations releases storage that is reserved on the 
disk (the extent caching, as well as files marked for delete), though 
that storage is reported (or released) with the ANALYZE /DISK (/REPAIR) 
command.

It's this second area that you're drilling into with your questions on 
journaling and log-structured file systems and such.   Which is 
arguably different from the free space skew — whether that skew was 
secondary to a crash, corruption and/or bug — that started the thread.  
Disk data is correct and consistent.   OpenVMS itself can be configured 
to perform a rebuild on boot for the system disk and the rebuild can be 
controlled on volume mount, or that step can be skipped to allow faster 
access to the storage for any of various reasons, such as to allow the 
rebuild to be performed on a host with a faster I/O connection to the 
disk.   (Rebuilding a disk via NI — which is pretty much Phillip's 
entire cluster — is much slower, and can end up with the whole cluster 
boot wedged behind some rinky-dink box with a soda-straw served pipe to 
the disk.  Rebuilding the disk with a more direct I/O path and not via 
an NI-based MSCP-served path is usually preferable.)

Here is a discussion of this particular topic from some sixteen years 
ago:  http://h71000.www7.hp.com/wizard/wiz_4080.html


-- 
Pure Personal Opinion | HoffmanLabs LLC