>>>>> "Scott" == Scott M Gelb via Toasters <toasters@teaparty.net> writes:
Scott> From: Scott M Gelb <scottgelb@yahoo.com>
Scott> To: "toasters@teaparty.net" <toasters@teaparty.net>, Eric Peng <epeng@esri.com>
Scott> Date: Tue, 24 Jul 2018 21:34:46 +0000 (UTC)
Scott> Subject: Re: SnapMirror Bi-directional possible?
Scott> For the same data set, bi-directional, you might want to POC Peer Software.
Scott> They PeerSync bi-directional and also have PeerLink which locks files on either
Scott> side while keeping in sync. FPOLICY is used for real time event notification
Scott> without file scans.
And from my experience with fpolicy and CommVault for HSM (Archiving
of old files) it's fragile as all hell and not reliable. When fpolicy
goes down... all hell will break loose.
And what happens when you have two different people editing the same
file at seperate sites? Last edit wins? This way lies sanity... you
need a cluster aware filesystems.
Of course people will point out that you have the same problem with
NFS if you edit the same file from two seperate clients at the same
site. It just silently uses the last one to write is the answer.
But for remote sites with fpolicy, I'm sure it will be even more
fragile.
John
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Scott> From: Scott M Gelb <scottgelb@yahoo.com>
Scott> To: "toasters@teaparty.net" <toasters@teaparty.net>, Eric Peng <epeng@esri.com>
Scott> Date: Tue, 24 Jul 2018 21:34:46 +0000 (UTC)
Scott> Subject: Re: SnapMirror Bi-directional possible?
Scott> For the same data set, bi-directional, you might want to POC Peer Software.
Scott> They PeerSync bi-directional and also have PeerLink which locks files on either
Scott> side while keeping in sync. FPOLICY is used for real time event notification
Scott> without file scans.
And from my experience with fpolicy and CommVault for HSM (Archiving
of old files) it's fragile as all hell and not reliable. When fpolicy
goes down... all hell will break loose.
And what happens when you have two different people editing the same
file at seperate sites? Last edit wins? This way lies sanity... you
need a cluster aware filesystems.
Of course people will point out that you have the same problem with
NFS if you edit the same file from two seperate clients at the same
site. It just silently uses the last one to write is the answer.
But for remote sites with fpolicy, I'm sure it will be even more
fragile.
John
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters