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

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 18-Jun-16 8:03 PM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Re; Spiralog, RMS Journaling (was Re:
> FREESPADRIFT)
> 
> On 2016-06-18 22:57:50 +0000, Kerry Main said:
> 
> > You are missing the point.
> 
> Um, no.   I'm not.  I know exactly what approach you are following, I
> am very familiar with DT as implemented on OpenVMS, and I've seen it
> fail utterly for products and for the competitiveness of more than a
> few organizations.   General requirements and expectations — not losing
> transactions — can be provided in different ways.   Sometimes in very
> different ways.   Speeds, feeds, features, tools and designs change.

I am not talking about just OpenVMS . This is platform agnostic and not 
specific to any OS. It is also a timeless core principle that is not likely 
going to change any time soon.

As I stated in my previous reply, by its very nature, write back & asynch
update strategies increase the risk of a significant event (site lost or 
system halted due to HW issue?) causing one to lose data. 

When you tell an application that the update was completed, and yet
no form of data persistence has taken place that transcends at least
2 sites, then there is a risk that data will be lost in the event of a site 
and or server being lost. 

Remember that a site being lost could be complete and permanent, 
so system and SAN battery type solutions are only short term risk 
mitigations. 

This is not to say that asynch/write back are not valid strategies, but 
they are cost/benefit/risk tradeoffs that depends on what the potential 
impact is should the significant event really occur.

This is the basics of RPO=0 discussions when doing DR planning. If the
business states it can live with something other than RPO=0, then 
certainly it makes sense to look at alternative solutions.

[snip]

Regards,

Kerry Main
Kerry dot main at starkgaming dot com