Re: Flames over -- Re: Which is simpler?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Pavel Machek wrote:
Provided that you sync before suspending, and there are no open files on the filesystem, then yes, no data will be lost. If there are open files on the fs, such as a half saved document, or a running binary, or say, the whole root fs, then you're going to loose data and even panic the kernel, sync or no sync. From the user perspective, this is
unacceptable.

While with your solution, you do not loose one open file, you loose
whole filesystem. Which is unacceptable.


Only if the user is foolish enough to modify the media somehow while the system is suspended and replace it, which is exactly how non USB disks currently behave.

Why should the user give up such functionality just because the connection to the drive thy are using is USB? Every other type of drive and interface does not suffer from this problem.

Because it is okay to unplug usb disk on runtime, while it is not okay
to unplug ATA disk on runtime. And because alternatives suck even more.


Actually, no, it is not okay to unplug a usb disk at runtime while it is mounted. It never has been and it never will be. Also we aren't talking about runtime, we're talking about while the system is suspended, when there is no way for the kernel to know whether or not the device was unplugged, since it _allways_ appears to have been unplugged. The alternative in the uncommon case ( where the user modifies the media while suspended ) does not suck any worse than it currently does on non usb media, and the common case ( where the user doesn't ) sucks worse currently with usb than others.

Maybe Linux should take a page from windows' playbook here. I believe windows handles this scenario with a USB drive the same way it does when you eject a floppy and reinsert it. The driver detects that the media/drive _may_ have changed and so it fails requests from the filesystem with an error code indicating this. The filesystem then sets an override flag so it can send down some reads to verify the media. Generally the FS reads the super block and compares it with the in memory one to make sure it appears to be the same media, and if so, continues normal access without data loss.

Feel free to implement that.
								Pavel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux