linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Braam <braam@clusterfs.com>
To: David Chow <davidchow@shaolinmicro.com>
Cc: Andreas Dilger <adilger@clusterfs.com>, linux-fsdevel@vger.kernel.org
Subject: Re: [ANNOUNCE] Lustre Lite 1.0 beta 1
Date: Mon, 17 Mar 2003 10:47:23 -0700	[thread overview]
Message-ID: <20030317174723.GG12121@peter.cfs> (raw)
In-Reply-To: <3E76024E.9060607@shaolinmicro.com>

> Andreas,
> 
> Thanks for your lengthly explanation. The design looked like Coda with 
> OST as you refer to the actual data storage. In fact, it is a stacked 
> file cache or your store data in files persistently on existing file 
> systesms. However, how can it handle a disconnected storage server? 
> Where this is the most diffcult problem for any cluster file systems 
> that support disconnection. It is obviously not allow disconnection for 
> system like having thousands of nodes is bad. The chance of node failure 
> is very high in those cases. As file allocation is still allowed to be 
> done across multiple storage servers. The answer to resolving data 
> conflicts transparently after disconnection is impossible! I would 
> really like to hear this from Lustre as it already played around with 
> 1000 nodes. When I came down to design a distributed file system end up 
> blowing my head about this. Thanks for comments or may yo give some 
> directions for me as I am very interested in this topic.
> 
> regards,
> David Chow

Hi David, 

Lustre recovers from client failures and clients recover from server
failures, but does not allow disconnected operations.  Disconnected
operation referes to the ability to make updates when the clients are
not connected to the servers.

The Lustre architecture does allow for modular extensions that enable
disconnected operation, but no customers have asked for it yet.

We have designed a very simple, automatic algortithm for handling
conflicts arising during disconnected operations for InterMezzo, see
the paper on www.inter-mezzo.org.  Again, this could be implemented
for Lustre, but we are waiting for a contract before we will do this.

Disconnected operation would involve a client cache, which will be
many many times slower than the distributed network infrastructure
when the file sizes exceed what can be cached in memory on the
client.   This is unusual but quite important for supercomputing and
some industrial applications.

- Peter -

      parent reply	other threads:[~2003-03-17 17:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-12 17:56 [ANNOUNCE] Lustre Lite 1.0 beta 1 Peter Braam
2003-03-16  5:38 ` David Chow
2003-03-16  8:38   ` Andreas Dilger
2003-03-17 17:13     ` David Chow
2003-03-17 17:46       ` Andreas Dilger
2003-03-17 17:47       ` Peter Braam [this message]

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=20030317174723.GG12121@peter.cfs \
    --to=braam@clusterfs.com \
    --cc=adilger@clusterfs.com \
    --cc=davidchow@shaolinmicro.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).