Hello John,


>>>>> "John" == John Wagner <[log in to unmask]> writes:

    John> Troy Dawson wrote:
    >> Brett Viren wrote:
    >>> John Rowe <[log in to unmask]> writes:
    >>> 
    >>> 
    >>>> The options would seem to be:
    >>>> 
    >>>> * AFS *GFS
    >>>
    >>  GFS is really geared towards all of the machines having access
    >> to the disk by fiber chanel, or some similar way, and all being
    >> able to write to the disk.  Not for one machine having access
    >> to the files and sharing it to all the others (which is more of
    >> what I picture a NFS replacement being.)

    John> GFS also provides a 2 tier access method by utilizing the
    John> GNBD (Generalized Network Block Device) method of serving up
    John> the data storage area. In this model a number of nodes can
    John> be designated as I/O serving nodes and they serve up a SAN
    John> based storage area to the other nodes. The only stipulation
    John> is that all the I/O nodes must see (or be connected to) the
    John> same storage area. So for instance, if you had a 10TB SAN
    John> which allowed 4 hosts to connect to it then you could have
    John> up to 4 I/O serving nodes with FC connection to the
    John> SAN. Each of these nodes would then export a quarter of the
    John> file storage space as a network block device. Each GFS
    John> client system (typically the compute nodes) imports the 4
    John> network block devices and constructs a single filesystem
    John> using the GFS pooling mechanism (this is basically a logical
    John> volume manager built into GFS). Thus you get file block
    John> striping over the 4 I/O servers with the obvious gains in
    John> I/O throughput. (Actually you have to configure striping as
    John> by default it does not do this).

Unfortunately, it seems RedHat discontinued the support for GFS over
multipathed gnbd in the 4.* versions of RHEL. What they actually
advice is to use iSCSI. I think this is related to the recent
(partial?) rewrite of the device mapper.
Bye,
e.

-- 
Enrico Sirola <[log in to unmask]>