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

[Stephen Hoffman]

On 2016-06-17 00:23:13 +0000, lawrencedo99 at gmail.com said:

> On Friday, June 17, 2016 at 11:57:02 AM UTC+12, Stephen Hoffman wrote:
> 
>> RMS Journaling: http://h71000.www7.hp.com/doc/72final/4454/4454pro.html
> 
> But not filesystem journalling.

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.  
Application data that's in flight might not fair well in these cases — 
this being at the core of why I'm skeptical around storage-level 
clustering and storage-level replication, in the absence of insight 
into the host software activity and state — but the file system should 
survive intact.

The combination of careful write ordering and the fondness for writing 
everything to disk is also related to why the OpenVMS file systems are 
comparatively slow.

Applications that depend on multi-part writes — few don't depend on 
that, of course — tend to either use a database or they use RMS 
journaling,  This if they need to ensure all writes related to an 
operation are committed, or that no writes are committed.

Spiralog was a log structured file system, which effectively means the 
whole file system was the journal.

Spiralog did not react particularly gracefully to a full-disk 
condition, but that's fodder for another day.

This is part of why I've been requesting an OpenVMS-integrated database 
— more than a few sites and OpenVMS itself aren't in a position to fund 
an Oracle purchase for this purpose — and the changes in storage 
technologies presently underway are also why I've been wondering 
whether the VSI new file system is flash / 3D Xpoint / SSD aware.

q.v. 
http://arstechnica.com/apple/2016/06/digging-into-the-dev-documentation-for-apfs-apples-new-file-system/ 



-- 
Pure Personal Opinion | HoffmanLabs LLC