[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1GjN7s-00024n-VV@be1.lrz>
Date: Sun, 12 Nov 2006 22:44:28 +0100
From: Bodo Eggert <7eggert@....de>
To: Ingo Molnar <mingo@...e.hu>, Mikael Pettersson <mikpe@...uu.se>,
akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [patch] floppy: suspend/resume fix
Russell King <rmk+lkml@....linux.org.uk> wrote:
> At a guess, what's probably happening is that the floppy drive, when
> powered on after resume, reports "disk changed" because it doesn't
> know any better.
>
> We interpret "disk changed" to mean the disk has been removed and
> possibly changed (which _is_ correct) and thereby abort any further
> IO (irrespective of resume.)
>
> Now, consider the following two scenarios:
>
> 1. You suspend and then resume, leaving the disk in the floppy drive.
>
> 2. You suspend, remove the floppy disk, insert a totally different disk
> in the same drive, and then resume.
>
> What should you do? (Hint: without reading the disk and comparing it
> with what you have cached you don't know if the disk has been changed
> or not.)
>
> If you argue that in case (1) you should continue to allow IO, then
> you potentially end up scribbling over a disk when someone does (2).
>
> So I'd argue that the behaviour being seen by Mikael is the _safest_
> behaviour, and the most correct behaviour given the limitations of
> the hardware.
- If a user suspends with a floppy in the drive, it will mostly be an error,
and he'll unsuspend in order to correct it.
- If it is no error, putting a different/modified floppy into the drive
before resume is unlikely
- Even if somebody does this, you can mostly detect the different disk
by comparing the first sector or just the FAT "serial number".
Therefore you can implement a relatively safe resume that will mostly DTRT
but destroy data in some unlikely cases, while doing the "safe thing" would
mostly cause a harmless (unless not noticed) kind of data loss and sometimes
safe you from real data loss.
I think you should let the user choose which foot to shoot.
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
http://david.woodhou.se/why-not-spf.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists