From: Andreas Dilger <adilger@sun.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] SNS and existing Lustre striping.
Date: Thu, 20 Dec 2007 15:46:09 -0700 [thread overview]
Message-ID: <20071220224609.GD3214@webber.adilger.int> (raw)
In-Reply-To: <476AD60C.1080803@sun.com>
On Dec 20, 2007 13:52 -0700, Peter Braam wrote:
> I was hoping for 1. to keep things simple.
Presumably, an SNS layer would replace (or just extend?) the existing
LOV functionality on the clients. We would definitely want to allow
existing RAID 0 striped files to be usable by having the SNS-aware client
understand the old LOV EA format, even if all new files are created with
an enhanced SNS EA format.
One feature that is quite desirable with SNS is to be able to add and
remove full mirrors of the file (as opposed to restriping to change the
layout in more complex ways) in an efficient manner. Since this
functionality is already required to be able to reconstruct a missing
mirror copy of a file it seems relatively straightforward to create a
"ghost" mirror copy and then have the normal resync mechanism copy it.
More complex layout changes (e.g. RAID0 striping to RAID5/6) can be
done via the planned normal file migration/restripe mechanisms, and it
should be up to the administrator to do this, as for some cases (e.g.
scratch filesystem) it might not be worth the extra IO to restripe all
the files and instead leave it up to normal file aging/purge to catch
most of the files, and then have a later pass later to handle files that
have a longer lifetimes.
> Alexander Zarochentsev wrote:
> > Coming SNS feature somehow duplicates and extents existing Lustre
> > striping functionality. How will they (SNS and striping) coexist
> > in the future versions of Lustre?
> >
> > I see 3 possible variants:
> >
> > 1. SNS replaces striping everywhere.
> > 2. one file can be SNS striped object or lustre striping object.
> > 3. one file can be SNS on top of Lustre-striping or Lustre-striping on
> > SNS and, probably, one part of file can be SNS and another part is
> > Lustre-striped.
> >
> > Does #3 makes any sense?
> >
> > I would prefer to assume that correct answer is (2) -- there are SNS
> > files and Lustre-striped files, because Lustre-striped files probably
> > have less overhead.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
prev parent reply other threads:[~2007-12-20 22:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200712202333.57536.alexander.zarochentsev@sun.com>
2007-12-20 20:52 ` [Lustre-devel] SNS and existing Lustre striping Peter Braam
2007-12-20 22:46 ` Andreas Dilger [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=20071220224609.GD3214@webber.adilger.int \
--to=adilger@sun.com \
--cc=lustre-devel@lists.lustre.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.