public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com
Subject: Re: [RFC 3/3] Future Directions - Reliability
Date: Wed, 24 Sep 2008 20:39:22 -0400	[thread overview]
Message-ID: <20080925003922.GA11841@infradead.org> (raw)
In-Reply-To: <20080923080504.GD5448@disturbed>

On Tue, Sep 23, 2008 at 06:05:04PM +1000, Dave Chinner wrote:
> Another failures that we often have reported is that XFS has 'hung' and
> traige indicates that the filesystem appears to be waiting for a metadata
> I/O completion to occur. We have seen in the past I/O errors not being
> propagated from the lower layers back into the filesystem causing these
> sort of problems. We have also seen cases where there have been silent
> I/O errors and the first thing to go wrong is 'XFS has hung'.
> 
> To catch situations like this, we need to track all I/O we have in flight and
> have some method of timing them out.  That is, if we haven't completed the I/O
> in N seconds, issue a warning and enter an exception handling process that
> attempts to deal with the problem.
> 
> My initial thoughts on this is that it could be implemented via the MRU cache
> without much extra code being needed.  The complexity with this is that we
> can't catch data read I/O because we use the generic I/O path for read. We do
> our own data write and metadata read/write, so we can easily add hooks to track
> all these types of I/O. Hence we will initially target just metadata I/O as
> this would only need to hook into the xfs_buf I/O submission layer.

I don't think this is something we want to do in XFS itself, as this
would fit much better in the bio layer (and propagation through the
pagecache).  That way we have it in one places instead of growing this
in various filesystems later on.

      reply	other threads:[~2008-09-25  0:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-23  7:59 [RFC 0/3] Future Directions for XFS Dave Chinner
2008-09-23  8:02 ` [RFC 1/3] Future Directions - Inode Subsystems Dave Chinner
2008-09-23  8:03 ` [RFC 2/3] Future Directions - Journalling Dave Chinner
2008-09-23  8:05 ` [RFC 3/3] Future Directions - Reliability Dave Chinner
2008-09-25  0:39   ` Christoph Hellwig [this message]

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=20080925003922.GA11841@infradead.org \
    --to=hch@infradead.org \
    --cc=xfs@oss.sgi.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