From mboxrd@z Thu Jan 1 00:00:00 1970 From: Coywolf Qi Hunt Subject: Re: [RFD] What error should FS return when I/O failure occurs? Date: Tue, 17 May 2005 06:57:10 +0800 Message-ID: <2cd57c90050516155720b0f3be@mail.gmail.com> References: <200505160635.j4G6ZUcX023810@turing-police.cc.vt.edu> <20050517.051113.132843723.okuyamak@dd.iij4u.or.jp> <200505162035.j4GKZVCc018357@turing-police.cc.vt.edu> <20050517.063931.91280786.okuyamak@dd.iij4u.or.jp> Reply-To: coywolf@lovecn.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Valdis.Kletnieks@vt.edu, fs@ercist.iscas.ac.cn, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: Received: from wproxy.gmail.com ([64.233.184.205]:34279 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S261294AbVEPW5L convert rfc822-to-8bit (ORCPT ); Mon, 16 May 2005 18:57:11 -0400 Received: by wproxy.gmail.com with SMTP id 68so2489064wra for ; Mon, 16 May 2005 15:57:10 -0700 (PDT) To: Kenichi Okuyama In-Reply-To: <20050517.063931.91280786.okuyamak@dd.iij4u.or.jp> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 5/17/05, Kenichi Okuyama wrote: > >>>>> "Valdis" == Valdis Kletnieks 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/