From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Integrity and corruption - can file systems be scalable?
Date: Fri, 2 Jul 2010 17:35:08 -0500 [thread overview]
Message-ID: <20100702223508.GH15407@oracle.com> (raw)
In-Reply-To: <20100702222151.GG15407@oracle.com>
I explained why well-delineated transactions help, but didn't really
explain why COW and Merkle hash trees help. COW helps ensure that
correct transactions cannot result in incorrect filesystems -- fsck need
only ensure that a transaction hasn't overwritten live blocks to
guarantee that one can at least rollback to that transaction. Merkle
hash trees help detect (and recover from) bit rot and hardware errors,
which in turn helps ensure that those incremental fscks are dealing with
correct meta-data (correct fsck code + bad meta-data == bad fsck).
It's much harder to ensure that there are no errors in parts of the
system that are exposed due to lack of special protection features (such
as ECC memory), in system buses and CPUs, that might be difficult or
impossible to protect against in software. One option is to run the
fscks on different hosts than the ones doing the writing (this means
multi-pathing though, which complicates the overall system, but at least
we currently depend on multipathing anyways). But even that won't
protect against such unprotectable errors in _data_ (originating in
faraway clients, say).
Nico
--
next prev parent reply other threads:[~2010-07-02 22:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-02 18:53 [Lustre-devel] Integrity and corruption - can file systems be scalable? Peter Braam
2010-07-02 20:52 ` Dmitry Zogin
2010-07-02 20:59 ` Peter Braam
2010-07-02 21:09 ` Nicolas Williams
2010-07-02 21:18 ` Dmitry Zogin
2010-07-02 21:39 ` Peter Braam
2010-07-02 22:21 ` Nicolas Williams
2010-07-02 22:35 ` Nicolas Williams [this message]
2010-07-03 3:37 ` Dmitry Zogin
2010-07-04 23:56 ` Nicolas Williams
2010-07-05 3:53 ` Dmitry Zogin
2010-07-05 7:11 ` Mitchell Erblich
2010-07-05 17:58 ` Nicolas Williams
2010-07-07 6:57 ` [Lustre-devel] [Lustre-discuss] " Andreas Dilger
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=20100702223508.GH15407@oracle.com \
--to=nicolas.williams@oracle.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.