From: Jeff Mahoney <jeffm@novell.com>
To: Hans Reiser <reiser@namesys.com>
Cc: Alex Zarochentsev <zam@namesys.com>,
Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] I/O Error Handling for ReiserFS v3
Date: Tue, 05 Oct 2004 14:21:19 -0400 [thread overview]
Message-ID: <4162E61F.5000103@novell.com> (raw)
In-Reply-To: <4162DCAA.50902@namesys.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hans Reiser wrote:
| Alex Zarochentsev wrote:
|
|> On Tue, Oct 05, 2004 at 08:44:22AM -0700, Hans Reiser wrote:
|>
|>
|>> These have received design approval from zam (and thus me), but zam,
|>> did they receive stress testing by Elena under your guidance?
|>>
|>
|>
|> No. We have a long queue of test tasks. There are fsck.reiser4 testing,
|> reiser4/dmapper crashes and the benchmarks in the queue.
|>
| Well, we cannot let our process be a barrier to good patches getting in,
| so let me ask, Jeff, did you test each of these conditions you
| improved? How? Did anyone else test them?
The "testing" version of the code had a another conditional added to
each of the !buffer_update tests that allowed me to trigger an I/O error
handling at each error point. The I/O error path is obviously more
difficult to test in real-world conditions as I/O errors could be caused
by any number of failures.
The testing was done using fsx-linux, the LTP fsstress program, and
stress.sh, sometimes all at once.
This code has also been active in the SUSE Linux Enterprise Server 9
kernel for some time and has seen real-world testing to show that the
normal path is still working as expected.
The end result for the i/o error path is that the write operations still
happen, but the commit block is never written. This means that the end
result is essentially the same as a power outage at the point of
failure. The filesystem is then read-only until the user decides to
umount and correct the problem that caused the I/O error in the first place.
- -Jeff
- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBYuYfLPWxlyuTD7IRAt1OAJ9RgkYWrCKikftGephpWWGlS+acSQCgjDwm
cxcXvSVyldRsJZdagvatw0Y=
=DuY9
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-10-05 18:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-05 15:08 [PATCH 0/4] I/O Error Handling for ReiserFS v3 Jeffrey Mahoney
2004-10-05 15:44 ` Hans Reiser
2004-10-05 17:22 ` Alex Zarochentsev
2004-10-05 17:40 ` Hans Reiser
2004-10-05 18:21 ` Jeff Mahoney [this message]
2004-10-05 18:40 ` Hans Reiser
2004-10-05 15:45 ` Hans Reiser
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=4162E61F.5000103@novell.com \
--to=jeffm@novell.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=reiser@namesys.com \
--cc=zam@namesys.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 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.