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

[Elladan <elladan@eskimo.com>]

On Tue, May 17, 2005 at 06:39:31AM +0900, Kenichi Okuyama wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
> 
> 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?

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

This is basically the problem people have had with removable storage for
years...  You can't really solve it perfectly, since as you note one
could always place the storage in another machine and change it.

But I think it's instructive to note what most other systems have done
in this situation...  The solution seems similar in most cases, from eg.
Mac, Amiga, DOS, Windows, etc.

The typical solution is, when a removable device is yanked when dirty
blocks exist, is to keep the dirty blocks around, and put the device
into some sort of pending-reinsert state.

Then most systems typically display a large message to the user of the
form: "You idiot!  Put the disk/cd/flash/etc. back in!"

The cache and dirty blocks would then only be cleared on a user cancel.
If the same device (according to some ID test) reappears, then it's
reactivated and usage continues normally.

Obviously, this sort of approach requires some user interaction to get
right.  It has the distinct advantage of not throwing away the data the
user wrote after an inadvertant disconnect, for example if they thought
the device was done writing when it really wasn't.  It can also keep
from corrupting the FS metadata.

The downside is that it might not really work, if there wasn't a good
way to know when sectors actually are in stable storage, since a few
blocks could be lost around the time the device was pulled.

-J
-
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/