Re: [PATCH] ReiserFS v3 I/O error handling

[Alex Zarochentsev <zam@namesys.com>]

On Wed, Sep 15, 2004 at 09:47:45AM -0400, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alex Zarochentsev wrote:
> | * reiserfs-io-error-handling.diff
> | 	- Allows ReiserFS to gracefully handle I/O errors in critical
> | 	  code paths. The admin has the option to go read-only or panic.
> | 	  Since ReiserFS has no option to ignore the use of the journal,
> |         the "continue" method is not enabled.
> |
> |
> |> What reiserfs will do with already dirty blocks on the R/O fs.  Those
> blocks
> |> remain dirty, yes?
> |
> |> The whole patch is enough complex, one look is not enough :) I think
> Elena may
> |> do additional testing to be sure that nothing is broken while
> improving i/o
> |> handling.
> 
> Yes, blocks that are already dirty will remain dirty. This is safe.
> 

I just checked that what we discussed for reiser4 is a right thing :)
But it is not fully implemented yet :-/

> Here are the cases:
> * Transaction hasn't started yet, and the journal has aborted
> ~  - Deny the transaction start in do_journal_begin_r, returning -EROFS
> * Transaction has started, journal was aborted in the meantime
> ~  - Finish cleaning up, don't write the commit block, return -EIO
> ~    from do_journal_end
> * Transaction has completed, and aborts during flush_commit_list()
> ~  - Finish writing, but don't write commit block
> * Transaction has completed, and aborts during flush_journal_list()
> ~  - Finish writing, but don't update journal header
> 
> Since this is an error path for I/O errors, NOT internal
> inconsistencies, it's safe to continue writing to the disk so long as we
> do so with the expectation that whatever we write there will be handled
> elsewhere.
> 
> One of the tenets of journaling filesystems is that if the transaction
> isn't commited, it never existed. The I/O error handling code takes
> advantage of this by completing whatever I/O is outstanding, which makes
> the code *far* less intrusive. My initial implementation tried cleaning
> stuff up, and it's extremely involved for very little gain. 
> Once the
> journal has aborted, updates to the journal's state just don't happen.
> Yes, blocks get written into it -- but the commit block doesn't. The
> transaction isn't commited: It never existed. Outstanding journal
> flushes can still flush to the disk, but it won't update the journal
> header. The transaction can be replayed the next time the filesystem is
> mounted.
> 
> I view it like this: An aborted filesystem is no different than one on a
> system which has lost power. The journal protects us here. Nothing after
> reiserfs_abort() exists, since the journal operations aren't commited.
> There will be incomplete transactions and incomplete flushes, but that's
> what the journal is there to handle in the first place.
> 
> The admin will be able to perform the normal operations before umounting
> a filesystem (closing open files, chdir'ing out of it), and the
> filesystem will be umountable. The admin can check it, and remount if
> they choose.

I assume that was tested with some simulated i/o errors, wasn't it?.

> - -Jeff
> - --
> Jeff Mahoney
> SuSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFBSEgBLPWxlyuTD7IRAvyBAJ0XJW7eP6eThwSK6YT9K3hdxlTT0ACfTLxY
> LIJEucE1EisIn9VQPXon/dw=
> =cQx8
> -----END PGP SIGNATURE-----

-- 
Alex.