Linux NFS development
 help / color / mirror / Atom feed
From: Donavan Pantke <avatar@dcr.net>
To: "Lorn Kay" <lorn_kay@hotmail.com>,
	lmb@suse.de, nfs@lists.sourceforge.net, linux-ha@muc.de
Subject: Re: Re: NFS as a Cluster File System.
Date: Thu, 9 Jan 2003 18:45:36 -0500	[thread overview]
Message-ID: <200301091845.36063.avatar@dcr.net> (raw)
In-Reply-To: <F43H06Ym8Es5FEnoLH80000317f@hotmail.com>

On Thursday 09 January 2003 18:13, Lorn Kay wrote:

>
> Sorry, still confused about what a "CFS" really is. In "In Search Of
> Clusters" Gregory Pfister takes the position that a distributed file sy=
stem
> is what he calls a valid "single system image" file system, what I woul=
d
> take to mean a cluster file system (though he doesn't use those words).
>
> I guess you are saying a clustered file system isn't necessarily suppor=
ting
> a cluster of application servers but is itself stored on a cluster. (A
> single server can be the only server using a cluster file system.) ?
>

=09Typically, the term CFS refers to a set of servers that work on the sa=
me=20
storage at the same time. What this means is that my central storage syst=
em=20
could have multiple servers mounting a file system at the same time.=20
Currently, preforming this is still in development; the difficulty is tha=
t=20
all nodes have to tell each other in some way about exactly what they're=20
doing to keep from corrupting the data on storage. Until this matures for=
=20
production use (It's my presonal opinion that there are still too many bu=
gs=20
in current implementations), the next best answer is for a highly availab=
le=20
cluster of servers that handle data requests. This is where NFS comes in.=
=20
Although I agree that in some applications this isn't workable with NFS, =
I've=20
found it to be quite a boon. At my workplace, we have a great many machin=
es=20
accessing common data. We started with a M$ cluster using SMB, but the na=
ture=20
of the protocol means that when the cluster fails, each client can't acce=
ss=20
currently open files. they have to close and re-open each handle. The=20
stateless nature of NFSv3 and v2 is stateless. This means that a cluster =
can=20
fail over and clients simply pause requests untile the filesystem is=20
accessible again. Not a good soution for applications with very high resp=
onse=20
time requirements, but it works for us. BTW: When describing clusters her=
e=20
I'm referring to a active-passive pair of servers where resources move wh=
en a=20
failure has been detected.

=09Donavan Pantke


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2003-01-09 23:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-09 23:13 NFS as a Cluster File System Lorn Kay
2003-01-09 23:45 ` Donavan Pantke [this message]
2003-01-10  3:34 ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2003-01-14 16:01 Lever, Charles
2003-01-10 17:19 Lorn Kay
2003-01-12 21:29 ` Trond Myklebust
2003-01-10 14:51 Lever, Charles
2003-01-10 15:23 ` Brian Tinsley
2003-01-09 22:51 Lorn Kay
2003-01-10 15:01 ` Trond Myklebust
2003-01-10 17:38   ` Greg Lindahl
2003-01-12 21:23     ` Trond Myklebust
2003-01-09 19:39 Lorn Kay
2003-01-09 21:11 ` Brian Tinsley
2003-01-09 22:04   ` Brian Jackson
2003-01-09 23:02     ` Brian Tinsley
2003-01-09 21:29 ` Alan Robertson
2003-01-13 19:36   ` Neil Brown
2003-01-13 20:25     ` David B. Ritch
2003-01-13 20:40       ` Neil Brown
2003-01-13 20:50         ` David B. Ritch
2003-01-13 22:11           ` Neil Brown
2003-01-14 15:46     ` Trond Myklebust
2003-01-14 16:01       ` Kumaran Rajaram
2003-01-14 16:08         ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200301091845.36063.avatar@dcr.net \
    --to=avatar@dcr.net \
    --cc=linux-ha@muc.de \
    --cc=lmb@suse.de \
    --cc=lorn_kay@hotmail.com \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox