Summary: Disk sharing among differing servers

From: Brewer, Edward (BREWERE@OD.NIH.GOV)
Date: Tue Aug 06 2002 - 08:59:41 EDT


Admins,

        All of the responses are no. The intent was to find a way that
disks could be shared (one read/write the other read only) between two
dissimilar servers (tru64 and sun) without using NFS. The other constraint
was to have the information real time (or close to real time) so that rules
out using scp,rcp,rdist or any copying mechanism. Thanks for the responses,
the outcome was expected but the question was posed for a sanity check.

Responses:

Dr. Blinn:

Ignoring for the moment the fact that neither vendor is going to be
willing to claim any support for such a setup, let me ask what should
be an obvious question: what file system type that's supported for
read/write access in Tru64 5.1 Trucluster is understood by Solaris on
Sun servers? I believe you will find the answer is "none". NFS works.
Why is using it a problem for you? You *might* be able to find a way
to get this to work using raw disks, but even then you'd have to take
care of any "endian" issues yourself (mixed binary and text data in a
file can be a nightmare).

Sure. It's not an unreasonable dream -- in principle, the fibrechannel
SAN makes things like that possible. But in reality, you'd need to find
a common on-disk format, and there isn't much -- the ones that are most
likely to readable on both systems are not read-write on either (e.g.,
you could create an ISO-9660 image on the Tru64/TruCluster system and
blast it onto a disk-like volume in the SAN and it would look to both
systems like a CDROM, but that's not very useful in real life...).

Tom

Jim Lola:

We have done a lot of work on heterogeneous SANs in out computer lab. The
scenario you paint is attractive but not possible - based on our testing.
We
are now looking at using the 8.6S (Snapshot) firmware to see if we can
accomplish this.

Jim

alan@nabeth.cxo.cpqcorp.net:

        What's on the disk? Sun doesn't support AdvFS, so they
        wouldn't even be able to mount that. There are subtle
        differences in the UFS implementations, not the least of
        which are endian issues with binary integers. It is
        unlikely that you could cross mount a UFS between Tru64
        UNIX and Sun. ISO-9660 would be readable on both, but
        you'd have to explicitly write one of those to a raw
        disk. ISO-9660 is the CDROM format. There isn't a native
        writing capability for one in Tru64 UNIX.

        With raw disk partitions if you have a fair chance if the
        reading programs can handle any endian issues that might
        crop up. The way the two operating systems handle partitions
        is also different, so you'd have to use whole disk without
        consideration of a partition table or label.

        Even if there was a common file system between the two,
        writes to the one wouldn't be noticed by the other. At
        best you'd simply get stale data. At worst, the file
        system would consider mysterious changes to be file system
        corruption and would panic the system.

Dr. Udo Grabowski:

You usually cannot mount directly different OS-formatted disks on
different servers (there is a limited possibility to do this on
Linux for a few filesystems), simply because Unix is not Unix
(despite of its name...). So NFS is the only reliable way to do this.
Even mounting one disk on two servers of the same OS (non-clustered)
will not work (even not read-only), because the caching mechanisms will
quickly desynchronize the content view from both servers, so after a
while one of the servers will crash because of cache incoherence. The
Cluster software circumvents this problem.

Pat O'Brien:

I posed this question a few months ago formally though this medium, and
informally through several other methods open to myself. The answers were
no. It would seem that the readonly system would assume that the filesystem
wold be similar to a cdrom and not subject to change, and would not expect
the readonly fs to change. the fat so to speak would be read once, and
subsequece changes/additions/or subtractions would be unnoticed.

    



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:48 EDT