Re: [RFD] What error should FS return when I/O failure occurs?

[Valdis . Kletnieks]

On Mon, 16 May 2005 13:14:25 EDT, fs said:

> 1. For EXT3 partition , we mount it as RW, but when I/O occurs, the
>    I/O related functions return EROFS(ReadOnly?), while other FSes
>    return EIO.

Only the request that actually caused the I/O error (and thus causing the
system to re-mount the ext3 partition R/O) should get EIO.  EROFS is
the proper error for subsequent requests - because they're being rejected
because the filesystem is R/O.  EIO would be incorrect, because the I/O
wasn't even tried, much less errored - and there's a good chance that
subsequent I/O requests *wouldn't* pull an error. Manwhile, subsequent
requests don't even *know* whether the filesystem was remounted R/O due to
an error, or if some root user said 'mount -o remount,ro'.

> 2. Assume a program doing the following: open - write(async) - close
>    When user-mode app calls sys_write, for EXT2/JFS, no error 
>    returns, for EXT3, EROFS returns, for XFS/ReiserFS, EIO returns.

Remember that the request that actually hits an error could be from a
process that isn't even in existence anymore, if the page has been sitting
in the cache for a while and we're finally sending it to disk.  If you don't
believe me, try this on a machine with lots (1G or 2G or so) memory:

1) cd /usr/src/linux
2) tar cf - . | cat > /dev/null    # just to prime the disk cache
3) make                    # wait a few minutes for it to complete.
4) Now that the 'make' is done, type 'sync' and watch the disk lights blink.

Notice you're syncing the disk blocks written by the various sub-processes
of 'make', all of which are done and long gone.  Who do you report the EIO
to, on what write() request?

(For even more fun - what happens if it's kjournald pushing the blocks out,
not the 'sync' command? ;)

This isn't as easy as it looks....

Attachment: pgp00000.pgp
Description: PGP signature