From: Brad Boyer <flar@allandria.com>
To: Kenichi Okuyama <okuyamak@dd.iij4u.or.jp>
Cc: Valdis.Kletnieks@vt.edu, fs@ercist.iscas.ac.cn,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFD] What error should FS return when I/O failure occurs?
Date: Mon, 16 May 2005 15:04:45 -0700 [thread overview]
Message-ID: <20050516220445.GA3681@pants.nu> (raw)
In-Reply-To: <20050517.063931.91280786.okuyamak@dd.iij4u.or.jp>
On Tue, May 17, 2005 at 06:39:31AM +0900, Kenichi Okuyama wrote:
> 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.
This is a difficult problem, but it's not as completely invalid as
you seem to think. The use case I remember taking advantage of in
actual experience is from the classic MacOS. The way the mac handled
floppies was very interesting. There was a way to eject an HFS floppy
without unmounting it. Using this trick, you could have multiple disks
mounted using the same physical drive. It kept as much as it could
in RAM to be able to use the files, and the system would block on
unknown sectors until the correct disk was reinserted. However, it's
very difficult to get this level of usage without full knowledge all
the way from the device driver up to the UI. Since Apple controlled
the whole thing, they could get away with this. I'm not sure we could
do an equivalent thing in as different of an environment as we have.
They could tell apart each filesystem, notify the user when a different
disk was needed, and everything else to have a seamless experience.
Brad Boyer
flar@allandria.com
next prev parent reply other threads:[~2005-05-16 22:04 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-16 17:14 [RFD] What error should FS return when I/O failure occurs? fs
2005-05-16 6:35 ` Valdis.Kletnieks
2005-05-16 18:04 ` fs
2005-05-16 17:58 ` Valdis.Kletnieks
2005-05-17 16:47 ` fs
[not found] ` <200505171057.10540.vda@ilport.com.ua>
2005-05-17 19:41 ` fs
2005-05-16 20:11 ` Kenichi Okuyama
2005-05-16 20:35 ` Valdis.Kletnieks
2005-05-16 21:39 ` Kenichi Okuyama
2005-05-16 22:04 ` Brad Boyer [this message]
2005-05-16 22:30 ` Elladan
2005-05-17 6:17 ` Denis Vlasenko
2005-05-17 18:10 ` Bryan Henderson
2005-05-18 6:54 ` Denis Vlasenko
2005-05-17 21:26 ` Kenichi Okuyama
2005-05-19 15:44 ` Elladan
2005-05-16 22:57 ` Coywolf Qi Hunt
2005-05-16 22:54 ` Coywolf Qi Hunt
2005-05-17 16:06 ` fs
2005-05-16 17:36 ` Hans Reiser
2005-05-16 18:04 ` Bryan Henderson
-- strict thread matches above, loose matches on Subject: below --
2005-05-17 5:36 Hua Zhong (hzhong)
2005-05-17 16:55 ` fs
2005-05-17 6:00 Hua Zhong (hzhong)
2005-05-17 17:20 ` fs
[not found] <05May16.114248edt.32448@gpu.utcc.utoronto.ca>
2005-05-17 15:43 ` fs
2005-05-17 18:26 ` Bryan Henderson
2005-05-18 17:10 ` fs
2005-05-18 7:57 ` Valdis.Kletnieks
2005-05-18 19:06 ` Bryan Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050516220445.GA3681@pants.nu \
--to=flar@allandria.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=fs@ercist.iscas.ac.cn \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=okuyamak@dd.iij4u.or.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).