[DRBD-user] Re: loop device and eth0 loop-back + latest version

Nuno Tavares nunotavares at hotmail.com
Sat Apr 24 04:20:19 CEST 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Lars, Eugene, and Greg,

I'm merging the forks here. I did not describe the problem completely
being affraid of getting offtopic.
Here is the scenario:
I have 2 servers. I need to have /home on both servers in sync, so when a
user logs in on any of both he gets his preferences, files, etc. If he
logs into server1, creates a file, then logs off, then login into server2
the file HAS to be there. 

If possible, locking should be done on a "who
gets it first can lock it" basis. This means that if the user logs into
server1 and opens file for writing/update FOO.TXT, and then logs into
server2 (without logging off server1) and it opens file, then the file may
only be accessed READ-ONLY.

So, Greg, here are the pre-requisites:
Locking: Basic (the first to open it R/W, locks it R/O).
Performance: Real-Time
Fault-tolerance: Best if existent, but not strictly required (data is not
critical).
Number of nodes: 2, but I'd prefer not stricting scalability.
Licensing: GPL preferred, other non-paid are acceptable.

BTW, thanks for pointing out Luster, OCFS, and CFS. I've never heard of
them.

I'm already studying:
InterMezzo, CODA, OpenGFS, OpenAFS.
But I really can't figure out if any of these will do. They all seem to
exist for that extra (3rd) device.

Still, Greg, NFS/SMB seemed not-applicable, as I'm not using a third
storage device (so I can "import" the filesystem to each node).
What are you thinking, exactly?
You are right about the standard way, when using a third device. 
But for sync'ing both disks (each one being local to each node), I'd need
something like a cross-exported share. Like:
server1# mount -t nfs server2:/home /home
server2# mount -t nfs server1:/home /home
And this does not make sense to me. Am I missing something here?

Eugene, you mentined a third machine. That is out of question, for now. I
wouldn't have this problem, if I had it (which then would have to handle
failover). However, you mentioned a HA NFS server, which is somewhat what
I need - but you are using FC on hardware RAID. Can you do the HA NFS
without that third box?

Lars, you are already helping :)

And.. many thanks for the support. Any source of information will be
gladly accepted. I just don't know exactly where to look for, and how to
start. DRBD seemed very nice, even if not applicable.

Again, many thanks.

Em Fri, 23 Apr 2004 15:47:30 -0400, Greg Freemyer
escreveu:

> On Fri, 2004-04-23 at 13:55, Nuno Tavares wrote:
>> I'm confused.
>> 
>> Do you think OpenGFS is a solution to my problem?
> 
> First OpenGFS and GFS are 2 different things.  (That may be why you were
> confused.)
> 
> OpenGFS is GPL'd and primarily being worked on by 2 Intel engineers at
> present.
> 
> GFS is not GPL'd too my knowledge (but it is supposed at some point). It
> is produced by Sistina, which is owned by Redhat.
> 
> In the absence of machine failures, both will do what you want.
> 
> In the presence of failures, OpenGFS will not presently survive crashing
> of the computer running its lockserver.  It is working on fixing that,
> but you are in a hurry.
> 
> I don't know how fault-tolerant GFS is.
> 
> BTW: 
> The functionality you are requesting is very leading edge in Linux, so
> if I were you I would focus on writing up a comprehensive set of
> requirements, then posting to see if there is anything out there that
> meets your needs.  In your write-up, be sure to include locking,
> performance, fault-tolerance, number of nodes, and GPL vs. commercial
> solutions acceptable.  (There are at least 5 GPL solutions and 2
> commercial offerings I know of that meet your basic need, but they all
> have short-comings.  The biggest issue is fault-tolerance.)
> 
> Possible GPL packages:
> 
> OpenGFS 
> 	(lockserver not fault tolerant)
> OpenSSI's CFS 
> 	(They have some fault-tolerance, but I believe not full.)
> Luster 
> 	(Good faul-tolerance I believe, but designed for large numbers of
> computers)
> Intermezzo 
> 	(I don't know anything about it.)
> OCFS 
> 	(Oracle Cluster Filesystem.  I don't know anything about it.)
> 
> Commercial:
> GFS
> ??? (Another one I can't think of.)
> 
> And why is it that NFS and/or SMB are unacceptable?  They are the
> standard way to do this.
> 
> Greg

-- 
-
Nuno Tavares
http://nthq.cjb.net/





More information about the drbd-user mailing list