Re: [RFD] FS behavior (I/O failure) in kernel summit

[Dave Chinner <dgc@sgi.com>]

On Wed, Jun 15, 2005 at 01:39:02PM -0400, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hans Reiser wrote:
> > Jeff, would you be willing to make a proposal for what should be done? 
> > I would be interested in your suggestions.
> > 
> > Jeff Mahoney wrote:
> > 
> >>Hans -
> >>
> >>These tests must have been run on a kernel prior to 2.6.10-rc1. The I/O
> >>error code exhibits behavior similar to ext3, so (1b). There are still
> >>kinks to be worked out, but it's definitely not the "throw up our arms
> >>and give up" that it used to be.
> >>
> >>Implementing behavior 1a for ext3 and reiserfs should be fairly trivial
> >>- it just means that tests to check if the filesystem is in an aborted
> >>state ("shutdown" in xfs terms) need to added to the call path in some
> >>places, and be moved earlier in others.
> 
> Well it seems to me that all the XFS code does is check to see if the FS
> is in a shutdown state really early in the call path.

FYI, the up front checks in XFS are simply to stop new I/O from starting
if we're already in the shutdown state.

However, there's more than that in XFS - there's checks all through
it's I/O paths so that I/Os and transactions in flight at (or
started after) the time of the shutdown can be aborted before doing
further damage to a potentially corrupted filesystem. This part
cannot be done generically as it is intimately tied to the
filesystem.

It is also worth noting that XFS won't shutdown a filesystem on just
any I/O error. Shutdowns due to I/O errors only occur when the
failure has the potential to leave the filesystem in an inconsistent
state.  Hence any given operation can return different errors
depending on where the I/O error occurred in XFS and what effect
that I/O error has on the consistency of the filesystem.....

BTW, the correct list to use to get the attention of the XFS folk
is linux-xfs@oss.sgi.com.

Cheers,

Dave.
-- 
Dave Chinner
R&D Software Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/