Pavel Machek wrote:
Must?! Are you Linus or what?
Non sequitur.
You are missing this. In 1st case, no data is actually lost, because of
sync in suspend code;
while second case is "goodbye, filesystem".
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.
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.
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.
-
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]
