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

[Valdis . Kletnieks]

On Tue, 17 May 2005 05:11:13 +0900, Kenichi Okuyama said:

> According to QuFuPing's test, USB cable was UNPLUGGED. That means,
> device is gone, and device driver instantly (well.. within second or
> two) detected that fact.  How could ext3 mounted device that does
> not exist, as Read Only?

I thought we were talking about write requests - which were getting short-circuited
because the file system was R/O before we even tried to talk to the actual
file system.  No sense in queueing a write I/O when it's known to be R/O.

If you're trying to *read* from the now-absent disk and encounter a page
that's not already in the cache, yes, you'll probably be returning an EIO.

> I don't see the reason why cache is still available.
> # I mean why such a implementation is valid.
> 
> If storage is known to be lost by device driver, we should not use
> that cache anymore.

Why?  If the disk disappeared out from under us because it was an unplugged USB
device, there's at least a possibility of it reappearing via hotplug - presumably
if you verify the UUID that it's the *same* file system, hotplug could do a
'mount -o remount' and recover the situation....

(Of course, this may not be practical if we've already tried a write-out due to
memory pressure or the like, and may not fit well into the innards of the VFS - but
it's certainly not an outrageously daft thing to attempt - "User unplugged before
we finished writing, but we still have all the needed pages, so we can re-drive
the sync to disk as if nothing happened"....)

Attachment: pgp00000.pgp
Description: PGP signature