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

Coywolf Qi Hunt
2005-05-16T22:57:51Z

On 5/17/05, Kenichi Okuyama <okuyamak@dd.iij4u.or.jp> wrote:
> >>>>> "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?

When there's umount, the kernel has no way to know whether it will
come back (mount) or not. When there's mount -o remount, the device
has never gone.

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

--
Coywolf Qi Hunt