From: Nick Piggin <npiggin@suse.de>
To: steve@chygwyn.com
Cc: Andi Kleen <andi@firstfloor.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [patch] fs: improved handling of page and buffer IO errors
Date: Thu, 23 Oct 2008 13:15:00 +0200 [thread overview]
Message-ID: <20081023111500.GB7693@wotan.suse.de> (raw)
In-Reply-To: <20081023094416.GA6640@fogou.chygwyn.com>
On Thu, Oct 23, 2008 at 10:44:16AM +0100, steve@chygwyn.com wrote:
> Hi,
>
> On Thu, Oct 23, 2008 at 09:07:11AM +0200, Nick Piggin wrote:
> > On Thu, Oct 23, 2008 at 10:07:15AM +1100, Dave Chinner wrote:
> [snip]
> >
> > > You could do the same thing for metadata read operations. e.g. build
> > > a large directory structure, then do read operations on it (readdir,
> > > stat, etc) and inject errors into each of those. All filesystems
> > > should return the (EIO) error to the application in this case.
> > >
> > > Those two cases should be pretty generic and deterministic - they
> > > both avoid the difficult problem of determining what the response
> > > to an I/O error during metadata modifcation should be....
> >
> > Good suggestion.
> >
> > I'll see what I can do. I'm using the fault injection stuff, which I
> > don't think can distinguish metadata, so I might just have to work
> > out a bio flag or something we can send down to the block layer to
> > distinguish.
> >
> > Thanks,
> > Nick
> >
>
> Don't we already have such a flag? I know that its not set in all
> the correct places in GFS2 so far, but I've gradually been fixing
> them to include BIO_RW_META where appropriate.
That should probably work. It seems to be very incomplete (GFS2
being one of the few exceptions). Though adding more support in
ext2 and buffer layer should be enough for me to start with,
and shouldn't be too hard.
> Also it occurs to me that we can use FIEMAP to discover where a
> parciular file is and that would then allow us to target error
> injection at particular blocks of the file.
>
> Given that we can cover xattr blocks with FIEMAP too[*], and that at
> least with GFS2 and similar filesystems the inode number is the
> block number of the inode, the only thing that would be missing,
> in terms of locating inode data & metadata would be the indirect blocks,
That would be interesting. I'm finding it hard to come up with
good ways to trigger a lot of the cases just for single-file case,
so I won't need to do anything so advanced yet ;)
next prev parent reply other threads:[~2008-10-23 11:15 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-21 11:21 [patch] fs: improved handling of page and buffer IO errors Nick Piggin
2008-10-21 12:52 ` Miklos Szeredi
2008-10-21 12:59 ` steve
2008-10-21 13:14 ` Miklos Szeredi
2008-10-21 13:38 ` steve
2008-10-21 14:32 ` Miklos Szeredi
2008-10-21 15:09 ` steve
2008-10-21 16:13 ` Miklos Szeredi
2008-10-22 12:51 ` Jamie Lokier
2008-10-22 14:08 ` Miklos Szeredi
2008-10-21 14:35 ` Evgeniy Polyakov
2008-10-21 14:59 ` steve
2008-10-21 16:20 ` Miklos Szeredi
2008-10-21 16:25 ` steve
2008-10-21 16:28 ` Miklos Szeredi
2008-10-21 16:29 ` Matthew Wilcox
2008-10-22 12:48 ` Jamie Lokier
2008-10-22 13:45 ` Matthew Wilcox
2008-10-22 14:02 ` Miklos Szeredi
2008-10-22 14:35 ` Matthew Wilcox
2008-10-22 14:45 ` Miklos Szeredi
2008-10-23 13:48 ` Matthew Wilcox
2008-10-22 22:23 ` Mark Fasheh
2008-10-23 9:59 ` steve
2008-10-23 10:21 ` Nick Piggin
2008-10-23 10:52 ` steve
2008-10-23 11:07 ` Nick Piggin
2008-10-22 13:16 ` Nick Piggin
2008-10-22 20:09 ` Miklos Szeredi
2008-10-21 16:16 ` Andi Kleen
2008-10-21 16:30 ` steve
2008-10-22 10:31 ` Nick Piggin
2008-10-22 18:46 ` Brad Boyer
2008-10-22 20:19 ` Andi Kleen
2008-10-23 7:08 ` Nick Piggin
2008-10-22 23:07 ` Dave Chinner
2008-10-23 7:07 ` Nick Piggin
2008-10-23 9:44 ` steve
2008-10-23 11:15 ` Nick Piggin [this message]
2008-10-23 22:48 ` Dave Chinner
2008-10-24 1:05 ` Nick Piggin
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=20081023111500.GB7693@wotan.suse.de \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=steve@chygwyn.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).