Arne Joris wrote:
Good grief Bill, are you one of those people that type more as they
grow angrier ? Thank you for all your replies, but I'm starting to get
a bit ticked off by your rather abrasive style.

Then shape up, pay a *lot* better attention to what you've (at least
presumably) read before responding to it, and you'll stop deserving that
style.


If we can get back to what started this whole discussion, I stated that

... if your secondary site is not just a remote data vault
but an actual production site where people need access to the data, it
is pretty lame to have severs at the secondary site go over the WAN to
go read the data from the primary storage when they have a copy of the
data right there ! With a distributed block cache on top of
asynchronous data replication, you could have both sites do I/O to the
same volumes and access their local storage.

I never heard you make any successful arguments against this,

Then you just weren't listening. The better (software-based)
alternatives that I described allow users to access data with no more
inter-site synchronous (or asynchronous) activity than the low-level
kludge that you're touting - and in many cases considerably less such
activity. They also allow far more efficient updating, by supporting
file-(or application-)level write-back caching *above* the storage level
protected by established single-site persistence mechanisms (such as
journaling or careful update) and coordinated between sites by the same
mechanisms that multiple cooperating instances of a file system (or
application of any complexity) have to use *anyway*.

Keep reading what I wrote until you at least *begin* to understand it,
or stop bleating about how little respect your babbling has received.

your only
beef with me is that you claim it would be stupid to use a distributed
block cache appliance (yes I know you don't like that wording) to do
this, seeing how the only useful way for apps at the two sites to use
the data requires synchronous messaging between them anyway.

Thus obviating the need for any such proprietary, special-purpose, and
typically somewhat expensive hardware.


Then there was a whole lot of talk about VMS, I'm not sure why that was
relevant.

Primarily (as I've already noted) because of your drivel about
inter-site synchronization of this ilk being 'emerging technology'
rather than very old hat with a new shiny ribbon around it.

Despite increasing levels of toxicity (unilaterally from your
part I might add), I have kept on trying to argue that for certain
solutions, the appliance solution makes sense.

And you've failed in that attempt, save in cases where no better
solution already exists and there's some real need for what YottaYotta
offers. Those cases at a minimum *don't* include Oracle RAC (it has its
own, better, and more comprehensive software mechanisms to deploy here),
or systems like VMS (and IIRC HACMP on AIX), or situations where those
systems can be used as inter-site local file or database servers for
less competent clients - nor, of course, other situations where
moderately lackadaisical remote-site access is not that big a deal.

In other words, that space of "certain solutions [where] the appliance
solution makes sense" is at best a very narrow one, and YottaYotta's
rather limited success tends to reflect this.

I think you have been
thinking about clustered applications with tight coherency requirements
and can't or won't see beyond them.

As usual, you think incorrectly. I guess you just can't wrap what
passes for your intellect around the fact that clustering, even with
tight coherency, does not necessarily imply that site-local data can't
be accessed at all sites as long as said local data is not actively
being updated at the time of use (that's what VMS's distributed lock
management and distributed file system is largely about).

Of course, accessing site-local data is often not particularly important
at all, unless you're accessing it in bulk: as long as you can safely
access the *contents* of a large file reliably from local storage, the
fact that the file open operation may have taken an extra second because
it was performed 3,000 miles away tends not to be all that significant
(VMS doesn't do things that way - I just mention it to indicate that a
*range* of effective approaches exists between a comprehensive ability
to migrate *all* synchronization control and a more limited ability for
a centralized mechanism to farm out specific revocable permissions to
where they'll be useful).


I'm fine with the fact you think I deserve a newsgroup lashing for
arguing for something you are convinced is impossible or impractible,

Except that, once again, you just haven't been paying attention: you
already propped up that straw man before, and I already responded that
what you're describing is eminently possible and practical, just not
particularly useful in any general sense compared with the available
alternatives.

By the way, I notice that you didn't choose to respond to my implied
question about whether you have (or had) any relationship with
YottaYotta. Inquiring minds want to know...

- bill