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

[fs <fs@ercist.iscas.ac.cn>]

On Mon, 2005-06-13 at 16:13, Andreas Dilger wrote:

> > fs wrote:
> > >Dear Linus, Andrew Morton, and all FS maintainers,
> > >1) When I/O failure occurs(e.g.: unrecoverable media failure - USB
> > >unplug), FS should
> > >   a. shutdown the FS right now(XFS does this)
> > >   b. try to make the media serve as long as possible(EXT3 remounts 
> > >      read-only, cache is still valid for read)
> > >   c. do not care, just print some kernel debugging info(EXT2 JFS 
> > >      ReiserFS)
> 
> Actually, 1b is just the default behaviour for ext3 (because of journal
> errors).  It is also possible to mount the filesystem with error=panic,
> which will implement 1a, and it is also possible to mount ext2 with
> error=remount-ro (which is default on Debian for ext2) which implements
> 1b.  I don't think it is possible to get 1c behaviour for journal
> errors on ext3.
> 
> > >2) When I/O failure occurs, FS should
> > >   a. give a unified error
> > >   b. give errors according to the FS type

Of coz EIO is not always right. But suppose the same unplug action 
results different errors, just because of FS type? You think both EIO
and EROFS are right, what if new FS return EXXX? Even it's correct, the
community should AT LEAST define a set of error values which are 
considered right. So, the application user can handle these errors one
by one. If not, that means errno can't provide enough info, that's the
case of 3)c

Well, I give question 1) 2) and 3), they're just examples. FS developers
use 'de facto' standard, it's ambiguous. We need an accurate one.

> What is "unified error"?  Does this mean "-EIO" for all cases?  I also
> don't understand why this is so important to your application...  If
> you get an error back from the filesystem that isn't expected, that is
> generally a problem regardless of what the error is...
> 
> > >3) the returned errno should be
> > >   a. real cause of failure, e.g. USB unplug returns EIO
> > >   b. cause from FS, e.g. USB unplug made FS remount read-only,
> > >      so open(O_RDONLY) returns ENOENT while open(O_RDWR) returns
> > >      EROFS
> > >   c. errno means nothing, you already get -1, that's enough

> This doesn't make sense.  If the "real cause of failure" is that the
> journal code detected an inconsistency (it might not be an IO error at
> the time, just some structure that is not what it should be, maybe the
> user tried to format their partition while in use ;-) then the real
> error is that the journal turned the filesystem read-only.  In any case,
> you can't expect to get more information that "EIO", regardless of the
> root cause (e.g. ENOMEM causes async buffer read to not complete, caller
> checks buffer_uptodate() and it isn't uptodate, returns EIO).
> 
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.

yours,
----
Qu Fuping