Messages in this thread | | | Date | Tue, 17 May 2005 06:57:10 +0800 | From | Coywolf Qi Hunt <> | Subject | Re: [RFD] What error should FS return when I/O failure occurs? |
| |
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 http://sosdg.org/~coywolf/ - 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/
| |