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

[Kenichi Okuyama <okuyamak@dd.iij4u.or.jp>]

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

Valdis> 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?

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

Wrong. Did you check what Qu have said?

1) USB storage exist as READ/WRITE mounted.
2) Then he unplugged USB cable, making USB storage unavailble.
3) EXT3 FS reported the error EROFS.

So, it is at the time somewhere between "after USB cable unplug" and
"write(2) return" that EXT3 remounted the file system as RO.
It was not RO from beginning.


Valdis> If you're trying to *read* from the now-absent disk and encounter a page
Valdis> 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.

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

I don't think that's good idea.

USB storage is gone. And it SEEMS to came back.
But how do you know that it's images were not changed.

Blocks you have cached might have different image. If you remount
the file system, the cache image should be updated as well.

But very fact that *cache image should be updated* means, old cache
image was invalid. And when did it become invalid?

When it was gone.

Think about thing this way. There was USB storage and it's cached
image. Storage is somewhat gone. It never returned before reboot.
Was cache image valid after storage gone? Ofcourse not. That cache
is nothing more than old data which came from LOST, and NEVER COMING
BACK device.

If device did come back but with change, we must read the data from
storage again. Old cache image was useless, and was harmful.
If device did come back without change, we can read the data from
storage again.

No need to keep the cache image, taking risk of cache not being
valid, especially while you have no control over the storage.


By the way.

Try umount, and then mount it again manually for any device.  You'll
find all the cache images for that file system are gone.
If your assumption about cache is correct, why isn't this
umount/remount feature keeping the cache image?

You'll, at least, see that there is some inconsistency about cache
handling when we *umount->mount* and *remount*.

regards,
---- 
Kenichi OKuyama
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/