[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gfs-devel
Subject:    Re: GFS quesion
From:       Andrew Barry <barry () borg ! umn ! edu>
Date:       2000-04-04 4:44:06
[Download RAW message or body]

GFS does work on any block device on your linux system. This includes
scsi, ide, loopback devices, etc. It makes an admirable local file system.
However it really does no good if it can't be seen by more than one other
machine. Scsi devices with multiple buses or fibre channel devices are
perfectly fit for such a case. 

There are two similar products which can give you the operability of GFS
and much of the performance benefit, though they lack the reliability of
scsi/fc. You can share your drives using the linux network block driver
(nbd.) This is already in the standard kernel distributions. Alternately
you can use the gndb which Mike Tilstra has developed in house. It is
included in the GFS source distribution. There has been much discussion
about the developement paths of these two products, neither is perfectly
reliable, but I know that some effort is going into improving the gnbd
(right mike?). 

If you are using this for a senior project and not in a production
environment I'm sure that your instructors will understand the budget
restrictions you have, and you can use gnbd to simulate the functionality
of a shared device. You will need three linux computers. A, B, C. Machine
C will be your pseudo-disk, running the gnbd server. Machines A and B will
be your GFS clients. They will run the gnbd client to get access to the
disk on Machine C over the network. You can then build a GFS file system
on this block device. You can use the GLM lock server to supply the
locking needed for the file system. 

This is obviously not a very reliable setup, since failure in machine C
takes down the entire cluster, but it simulates the setup needed in a
production GFS system. 

Please note that the latest relase of GFS (antimatter anteater) will not
support journalling, so failure in one machine results in cluster wide
failure. We hope to have a new release out in (a integer number less than 
10) weeks. If this is not available by the time you need to be working on
this, you can work with the code from our CVS. (public cvs code
instructions are available on the GFS webpage.) It is kinda rough, but it
has journalling. It is kind of slow because the journalling is
synchronous, but that shouldn't matter much if you are serving NFS since
NFS is inherantly synchronous anyway and the performance sucks no matter
how you do it. The GFS-HOWTO on the web page is designed for the last
release, but should be mostly correct. If you have problems, feel free to
mail them to gfs-devel. 

Thank you for your interest. We are always glad to have more people
pounding on GFS, talking about GFS, telling their friends and professors
about GFS, etc. 

peace and good luck, 
Andrew-


Andrew Barry
barry@borg.umn.edu
borg - you will be assimilated

On Tue, 4 Apr 2000, Brian Cotterall wrote:

> To Andrew Barry,
> 		I am an engineering student from Griffith Uni in
> Australia. I have been looking at GFS and how it can be implemented in a
> high availability linux server distributed file system as part of my
> final year thesis. The question is "Does GFS exclusively use fibre and
> SCSI devices? If yes, do you know of another distributed file system
> that is similar to GFS? If no dose GFS support IDE and TCP/IP devices? 
> 
> 	Regards Brian Cotterall 
> 	from Down Under
> 


-
To unsubscribe from this list: send the line "unsubscribe gfs-devel" in
the body of a message to majordomo@borg.umn.edu
Read the GFS Howto:  http://www.globalfilesystem.org/howtos/gfs_howto/

[prev in list] [next in list] [prev in thread] [next in thread]