[Info-vax] FREESPADRIFT

[David Froble]

Paul Sture wrote:
> On 2016-06-17, David Froble <davef at tsoft-inc.com> wrote:
>> Paul Sture wrote:
>>> On 2016-06-16, lawrencedo99 at gmail.com <lawrencedo99 at gmail.com> wrote:
>>>> On Friday, June 17, 2016 at 6:24:46 AM UTC+12, Michael Moroney wrote:
>>>>
>>>>> Don't forget that Spiralog was newer than ODS-5/ODS-2.  And Spiralog was
>>>>> to be a different file system for VMS (not a mod to ODS-5) but was 
>>>>> cancelled.
>>>> Linux was able to add journalling to an existing filesystem (turning
>>>> ext2 into ext3). VMS never did the same?
>>> A mentioned by another poster, work was started on a new filesystem.
>>>
>>> We're back to where you spend the available resources - retrofitting
>>> a new feature to an existing system or implementing a replacement?
>>>
>>> The existing VMS filesystem doesn't cache writes as much as other file
>>> systems, and on-disk pointers are built in such a way that a power loss
>>> doesn't result in the damage you see on other file systems.
>>>
>>> I'd put it that the current VMS filesystem didn't need journalling as
>>> urgently as other filesystems.
>>>
>>> And yes, the relative certainty that when you write something to disk
>>> it the current VMS world, it does actually hit the disk, has been a
>>> limiting factor in performance.
>>>
>> But it sure helped when that $10M in accounts receivable wasn't lost ....
> 
> To be honest I cannot remember a single incident where either a crash
> or power failure caused wholesale loss of data on a VMS disk.
> 
> Yes, that backup/image restore or indexed file reorganisation which
> didn't complete due to a crash or power failure would be toast, but it
> would be pretty obvious what had happened.
> 
> Real life example from the early 2000s when a less-uninterruptible 
> power supply took out the power to a whole building:
> 
>     The VMS systems came back minus a few disks which didn't spin up.
>     Volume shadowing and the replacement of dead disks brought the
>     systems back to normal working order.  The applications on these
>     systems used a mix of Oracle Rdb and Oracle Classic, set up by
>     competent DBAs.
>     
>     In contrast some of the Unix systems (there were no Linux
>     deployments at that customer at that time) required full filesystem
>     restores from tape before they could be brought back into
>     production.  This took several days for the larger systems.
> 
> Footnote: some concrete figures for money lost by extended downtime
> came out of that incident and management was not afraid to invest
> in beefing up their disaster recovery capabilities.
> 

Too bad that it appears to be a case of closing the barn doors after the horses 
are out ....

:-)

But, better late than never ....