From: Dave Chinner <david@fromorbit.com>
To: Nick Piggin <npiggin@suse.de>
Cc: steve@chygwyn.com, 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: Fri, 24 Oct 2008 09:48:04 +1100 [thread overview]
Message-ID: <20081023224804.GD18495@disturbed> (raw)
In-Reply-To: <20081023111500.GB7693@wotan.suse.de>
On Thu, Oct 23, 2008 at 01:15:00PM +0200, Nick Piggin wrote:
> 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.
I've posted patches to tag XFS metadata with BIO_RW_META in the
past, but that patch set had performance implications for different I/O
schedulers so it never went further than just a patch. If I
leave all the BIO_RW_SYNC tagging for the metadata bios, then
a single line change to add BIO_RW_META should not have any
performance impact....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Nick Piggin <npiggin@suse.de>
Cc: steve@chygwyn.com, 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: Fri, 24 Oct 2008 09:48:04 +1100 [thread overview]
Message-ID: <20081023224804.GD18495@disturbed> (raw)
In-Reply-To: <20081023111500.GB7693@wotan.suse.de>
On Thu, Oct 23, 2008 at 01:15:00PM +0200, Nick Piggin wrote:
> 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.
I've posted patches to tag XFS metadata with BIO_RW_META in the
past, but that patch set had performance implications for different I/O
schedulers so it never went further than just a patch. If I
leave all the BIO_RW_SYNC tagging for the metadata bios, then
a single line change to add BIO_RW_META should not have any
performance impact....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-10-23 22:49 UTC|newest]
Thread overview: 81+ 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 11:21 ` Nick Piggin
2008-10-21 12:52 ` Miklos Szeredi
2008-10-21 12:52 ` Miklos Szeredi
2008-10-21 12:59 ` steve
2008-10-21 12:59 ` steve
2008-10-21 13:14 ` Miklos Szeredi
2008-10-21 13:14 ` Miklos Szeredi
2008-10-21 13:38 ` steve
2008-10-21 13:38 ` steve
2008-10-21 14:32 ` Miklos Szeredi
2008-10-21 14:32 ` Miklos Szeredi
2008-10-21 15:09 ` steve
2008-10-21 15:09 ` steve
2008-10-21 16:13 ` Miklos Szeredi
2008-10-21 16:13 ` Miklos Szeredi
2008-10-22 12:51 ` Jamie Lokier
2008-10-22 12:51 ` Jamie Lokier
2008-10-22 14:08 ` Miklos Szeredi
2008-10-22 14:08 ` Miklos Szeredi
2008-10-21 14:35 ` Evgeniy Polyakov
2008-10-21 14:35 ` Evgeniy Polyakov
2008-10-21 14:59 ` steve
2008-10-21 14:59 ` steve
2008-10-21 16:20 ` Miklos Szeredi
2008-10-21 16:20 ` Miklos Szeredi
2008-10-21 16:25 ` steve
2008-10-21 16:25 ` steve
2008-10-21 16:28 ` Miklos Szeredi
2008-10-21 16:28 ` Miklos Szeredi
2008-10-21 16:29 ` Matthew Wilcox
2008-10-21 16:29 ` Matthew Wilcox
2008-10-22 12:48 ` Jamie Lokier
2008-10-22 12:48 ` Jamie Lokier
2008-10-22 13:45 ` Matthew Wilcox
2008-10-22 13:45 ` Matthew Wilcox
2008-10-22 14:02 ` Miklos Szeredi
2008-10-22 14:02 ` Miklos Szeredi
2008-10-22 14:35 ` Matthew Wilcox
2008-10-22 14:45 ` Miklos Szeredi
2008-10-22 14:45 ` Miklos Szeredi
2008-10-23 13:48 ` Matthew Wilcox
2008-10-23 13:48 ` Matthew Wilcox
2008-10-22 22:23 ` Mark Fasheh
2008-10-22 22:23 ` Mark Fasheh
2008-10-23 9:59 ` steve
2008-10-23 9:59 ` steve
2008-10-23 10:21 ` Nick Piggin
2008-10-23 10:21 ` Nick Piggin
2008-10-23 10:52 ` steve
2008-10-23 10:52 ` steve
2008-10-23 11:07 ` Nick Piggin
2008-10-23 11:07 ` Nick Piggin
2008-10-22 13:16 ` Nick Piggin
2008-10-22 13:16 ` Nick Piggin
2008-10-22 20:09 ` Miklos Szeredi
2008-10-22 20:09 ` Miklos Szeredi
2008-10-21 16:16 ` Andi Kleen
2008-10-21 16:16 ` Andi Kleen
2008-10-21 16:30 ` steve
2008-10-21 16:30 ` steve
2008-10-22 10:31 ` Nick Piggin
2008-10-22 10:31 ` Nick Piggin
2008-10-22 18:46 ` Brad Boyer
2008-10-22 18:46 ` Brad Boyer
2008-10-22 20:19 ` Andi Kleen
2008-10-22 20:19 ` Andi Kleen
2008-10-23 7:08 ` Nick Piggin
2008-10-23 7:08 ` Nick Piggin
2008-10-22 23:07 ` Dave Chinner
2008-10-22 23:07 ` Dave Chinner
2008-10-23 7:07 ` Nick Piggin
2008-10-23 7:07 ` Nick Piggin
2008-10-23 9:44 ` steve
2008-10-23 9:44 ` steve
2008-10-23 11:15 ` Nick Piggin
2008-10-23 11:15 ` Nick Piggin
2008-10-23 22:48 ` Dave Chinner [this message]
2008-10-23 22:48 ` Dave Chinner
2008-10-24 1:05 ` Nick Piggin
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=20081023224804.GD18495@disturbed \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--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 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.