🚀 go-pugleaf

Bill,

You're right. I hadn't meant to imply that this wasn't the case, only that
the data request was via NFS, and the return was by SAN or IP depending on
which was more appropriate. The actual mechanism is as you described it: If
the data is IP friendly (ie a small file) the Celerra returns the data, if
the data is more appropriately routed via a SAN, the Celerra returns
metadata, and the Highroad client collects the file over the SAN.

 - Bill Meredith

"Bill Todd" <billtodd@foo.mv.com> wrote in message
news:9k83ec$7jn$1@pyrite.mv.net...
>
> "Bill Meredith" <wmeredit@idirect.com> wrote in message
> news:S8I97.41850$uH4.2282703@news20.bellglobal.com...
> > EMC has a product called Celerra Highroad (part of our NAS offering)
that
> > does what you're looking for. The Celerra is attached to the Symmetrix
> disk
> > array, and fields file requests made via standard NFS (or CIFS)
protocol.
> > The data is returned to the NFS client (in your case, the Sun servers)
> > accross the SAN.
>
> Is that really how it works?  My impression had been that the Celerra
server
> made the location of the desired data available to the client, and that
the
> client then requested it directly (rather than using a three-corneded
> sequence and device-level third-party transfers as you describe).  I'd
also
> suspected that where byte-range locking activity was not present the
client
> cached this location information (with appropriate recall provisions
should
> it change) such that it did not need to contact the Celerra server on
every
> data access.
>
> I realize that this requires extensions to the NFS and CIFS protocols used
> by the client, but it's not obvious how one could return information via
the
> SAN (rather than the request LAN) without such changes anyway.  One of the
> documents on the Web site you refer to at least seems to suggest that
things
> work as I described them above.  Hope you can provide more details if
these
> impressions are incorrect.
>
> - bill
>
>
>