All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: 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 03:05:04 +0200	[thread overview]
Message-ID: <20081024010504.GA5004@wotan.suse.de> (raw)
In-Reply-To: <20081023224804.GD18495@disturbed>

On Fri, Oct 24, 2008 at 09:48:04AM +1100, Dave Chinner wrote:
> 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 have a patch for (most of) buffer and ext2 btw. Seems to work OK.

 
> 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

Hmm, yes CFQ does do something with meta requests. It's a pity you
can't just add the annotations and file bugs with CFQ if it hurts
performance :P


> 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....

Sorry, I don't understand what you mean here. 

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: 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 03:05:04 +0200	[thread overview]
Message-ID: <20081024010504.GA5004@wotan.suse.de> (raw)
In-Reply-To: <20081023224804.GD18495@disturbed>

On Fri, Oct 24, 2008 at 09:48:04AM +1100, Dave Chinner wrote:
> 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 have a patch for (most of) buffer and ext2 btw. Seems to work OK.

 
> 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

Hmm, yes CFQ does do something with meta requests. It's a pity you
can't just add the annotations and file bugs with CFQ if it hurts
performance :P


> 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....

Sorry, I don't understand what you mean here. 

--
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>

  reply	other threads:[~2008-10-24  1:05 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
2008-10-23 22:48               ` Dave Chinner
2008-10-24  1:05               ` Nick Piggin [this message]
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=20081024010504.GA5004@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 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.