progress

openGFS , a kind of file system.

I do believe it is time for a progress update on GNBD.  Most of the
interesting changes reflect towards the cluster goals of gnbd.  There is
now an ioctl that lets you send four different actions to any of the
existing gnbd devices.  These actions let you change the IP and port of the
server, disconnect form a server, connect, and a force-close. (The
force-close exists mostly for debugging purposes)

The single thing that makes this most interesting is that if you send a
disconnect, or if contact to the server should die, processes accessing
that device do not die or return errors.  These processes are blocked, and
hopefully, sometime soon, a connect will be issued and IO can continue
where it had left off.

Gnbd does not make decisions about the state of the cluster.  It lets other
tools handle this, and just [attempts] to give a clean interface for doing
it.  The idea being that gnbd is set up and connected to somewhere.
Processes are working on the gnbd devices. If there is a loss of access to
the server, some other process (like, say heartbeat) will detect this, and
either find a new server that has the same data, or wait for the other
server to return from death.

The latest gnbd is in the OpenGFS cvs,
<http://opengfs,sourceforge.net> On how to get the
sources from there.  If enough people want, I'll pull out just gnbd, and
make its own tar ball.

I have only just done basic testing of all of this.  I'm about to start
going into more detailed testing, and would greatly appreciate if others
would also play with gnbd.  It would also be nice if people could tell me
what other features they would like to see. (Actually, if you have feature
requests, you can add them to the sourceforge bugtracker
<http://opengfs.sourceforge.net/> bugs you find can go there too)

And I'd love to give you all some really great documentation on how to use
gnbd.  But alas, none exists.  Most things are explained pretty well in the
source, and if not, I'll be glad to answer questions.

-------------------------------
7/21/00 Ben Marzinski ([e-mail])
O.k. now that gnbd has been taken back out of the closet, there is another
(growing) list of things to do.

1. Massive overhaul on the kernel server. It currently messes up the process
   table and only works on i386 machines through some gross hack. It currently
   doesn't work on alphas.

2. Find some workaround for the client server on one machine problem. Currently
   if both the client and servr are on one machine, it will lock-up on any
   nice sized IO request.

These two problems together probably warrent a big reworking of both the client
and the server.

3. Register gnbd block devices on /proc/partitions so that it is possible to use
   them in pools

4. Find bugs. Fix bugs

and more to come.

-------------------------
2000/07/31

gnbd devices now register on /proc/partitions. To do this, install the module,
# insmod gnbd.o
set the ip address and port
# gnbdtool SetIPPort /dev/gnbdb <some ip address> <some port>
yes, /dev/gnbdb used to be called /dev/gnbd1. Finally connect to the server
# gnbdtool Connect /dev/gnbdb
This just brings up a momentary connection, so that the gnbd client can get
the size information off of the server.
Then check /proc/partitions, and it should be there.
I don't believe you can actually partition this device, nor do I know just what
bad things would happen if you actually succeeded.

And more things to add to my already backlogged list

5. Fix the states in /proc/gnbd (just for fun)

6. Write up documentation

-------------------------
2000/08/08

The process handling is much prettier now. The gross hack was removed, and
everything should work fine on all platforms. (knock on plastic) The next bunch
of commits will probably be bux fixes for bugs that come up during hardcore
testing. It'll probably also involve beefing up /proc/gnbd (it the future it
might even contain information that is correct AND useful!).  There's still the
issue with a client and server on the same machine, which I'm putting off as
long as possible on account of it being hard (I think.. anyone with bright
ideas is more than welcome to tell me)

also look for real documentation soon!!!!

-------------------------
2001/09/01

Became part of OpenGFS after sistina turned into the bad guys

-------------------------
2001/12/01	Christoph Hellwig

Moved into it's own package