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

Valdis.Kletnieks
2005-05-16T20:36:36Z

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

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 #2: Type: application/pgp-signature, Size: 226 bytes --]