linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Ric Wheeler <ric@emc.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: topics for the file system mini-summit
Date: Sat, 27 May 2006 08:18:32 -0600	[thread overview]
Message-ID: <20060527141832.GT5964@schatzie.adilger.int> (raw)
In-Reply-To: <4477A236.3040208@emc.com>

On May 26, 2006  20:49 -0400, Ric Wheeler wrote:
> Andreas Dilger wrote:
> >In a way what you describe is Lustre - it aggregates multiple "smaller"
> >filesystems into a single large filesystem from the application POV
> >(though in many cases "smaller" filesystems are 2TB).  It runs e2fsck
> >in parallel if needed, has smart object allocation (clients do delayed
> >allocation, can load balance across storage targets, etc), can run with
> >down storage targets.
>
> The approach that lustre takes here is great -  distributed systems 
> typically  take into account subcomponent failures as a fact of life & 
> do this better than many single system designs...
> 
> The challenge is still there on the "smaller" file systems that make up 
> Lustre - you can spend a lot of time waiting for just one fsck to finish ;-)

CFS is actually quite interested in improving the health and reliability
of the component filesystems also.  That is the reason for our interest
in the U. Wisconsin IRON filesystem work, which we are (slowly) working
to include into ext3.

This will also be our focus for upcoming filesystem work.  It is
relatively easy to make filesystems with 64-bit structures, but the
ability to run such large filesystems in the face of corruption
environments is the real challenge.  It isn't practical to need a
17-year e2fsck time, extrapolating 2TB e2fsck times to 2^48 block
filesystems.  A lot of the features in ZFS make sense in this regard.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.


  reply	other threads:[~2006-05-27 14:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-25 21:44 topics for the file system mini-summit Ric Wheeler
2006-05-26 16:48 ` Andreas Dilger
2006-05-27  0:49   ` Ric Wheeler
2006-05-27 14:18     ` Andreas Dilger [this message]
2006-05-28  1:44       ` Ric Wheeler
2006-05-29  0:11 ` Matthew Wilcox
2006-05-29  2:07   ` Ric Wheeler
2006-05-29 16:09     ` Andreas Dilger
2006-05-29 19:29       ` Ric Wheeler
2006-05-30  6:14         ` Andreas Dilger
2006-06-07 10:10       ` Stephen C. Tweedie
2006-06-07 14:03         ` Andi Kleen
2006-06-07 18:55         ` Andreas Dilger
2006-06-01  2:19 ` Valerie Henson
2006-06-01  2:42   ` Matthew Wilcox
2006-06-01  3:24     ` Valerie Henson
2006-06-01 12:45       ` Matthew Wilcox
2006-06-01 12:53         ` Arjan van de Ven
2006-06-01 20:06         ` Russell Cattelan
2006-06-02 11:27         ` Nathan Scott
2006-06-01  5:36   ` Andreas Dilger
2006-06-03 13:50   ` Ric Wheeler
2006-06-03 14:13     ` Arjan van de Ven
2006-06-03 15:07       ` Ric Wheeler

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=20060527141832.GT5964@schatzie.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ric@emc.com \
    /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).