All of lore.kernel.org
 help / color / mirror / Atom feed
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-----

  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.