Messages in this thread | | | Date | Mon, 26 May 2008 20:23:23 +0200 | From | Ingo Molnar <> | Subject | Re: Top 10 bugs/warnings for the week of March 23rd, 2008 |
| |
* Theodore Tso <tytso@mit.edu> wrote:
> > > Looking at the filesystem UUID could help -- this is an ID that is > > > present as data on the disk, and that is even independent of the > > > bus type. See also /dev/disk/by-uuid. > > Yes, but as Oliver wrote if someone modified the filesystem in the mean > > time, you won't notice it - UUID doesn't help here. > > That part you could figure out in userspace, by looking at the last > mount and last modified time in the superblock. But the problem is > it's too late. If you had buffers which had been "in flight" at the > time when the USB stick was pulled, the kernel isn't going to be able > to send them to the new instantiation of the device for the freshly > installed USB stick. And I don't think we want to put > filesystem-specific UUID and superblock parsing code in the generic > USB layer!
yeah, i agree it's all ugly - but it's really our making not the user's ;-)
i think we could and should go to quite some length to properly support a rather benign-appearing usecase such as the user removing stuff from a modern computer (stuff that is not specifically bolted down that is). Violating a few artificial abstraction layers within the kernel is a lot better than losing user data, IMHO.
Ingo
| |