On Monday, 2 April 2007 04:54, Alan Stern wrote: > On Sun, 1 Apr 2007, Rafael J. Wysocki wrote: > > > Hi, > > > > On Sunday, 1 April 2007 20:34, Pavel Machek wrote: > > > Hi! > > > > > > > > Problem is that suspending _with_ removable mass storage devices > > > > > attached just will not work. User will unplug them, then complain > > > > > about corruption. Advanced user will unplug them, work with them > > > > > somewhere else, replug them, then loose filesystem. > > > > > > > > > > Feel free to send patch to teach filesystems to handle this. > > > > > > > > Actually what's needed is a Persistent Logical Volume Manager. With it, > > > > you could even mount a filesystem on a USB device, unplug the device, > > > > plug > > > > it back into a different port, and still be able to use the filesystem. > > > > > > > > But you're still likely to run into trouble if you unplug a storage > > > > device, move it to another system and write on it, then plug it back > > > > into > > > > the original system. The PLVM would somehow have to recognize that the > > > > data had been changed. I don't know a foolproof way of doing that. > > > > > > Such detection should be possible when done at filesystem level. > > > > > > I.e. ext3 would notice that someone replayed the journal. > > > > > > Or we could create ext5 where each r/w mount would update mount > > > time... actually we probably already have last mount time in ext3, > > > so... > > > > I'm thinking we'll need to introduce something like freezing notifiers, ie. > > the ability to register a notifier by an interested subsystem that will be > > called right after user space processes have been frozen and right before > > we start to thaw them (that may allow us to handle the microcode issue in > > a clean way, for example). > > > > Now if a filesystem registers a freezing notifier, it may be unmounted > > during > > the suspend and remounted during the resume in more or less transparent > > way. I think an additional mount flag would be needed for filesystem that > > should install such notifiers, like "removable". > > "Unmounted" and "remounted" aren't quite the right words. All you really > need to do is check (during the resume) that the superblock is still in > the same state as it was when the suspend occurred.
Yes, I was thinking of something more sophisticated, but this is what we need. > After all, if someone > else had mounted the dirty filesystem during the interim, they surely > would have altered the superblock. Note that even a read-only mount of a > dirty ext3 filesystem will recover the journal; presumably that will alter > the superblock too. > > I don't think a "removable" flag is needed. There's no reason not to do > this for every mounted filesystem. Well, I'm afraid about such filesystems as vfat ... > (Also "removable" isn't the right word either, since hot-pluggable devices > with non-removable media would need the same treatment. In fact, while > the system is hibernating someone could even remove an internal IDE drive > and then put it back!) I meant the filesystems could be marked as "removable" rather than the devices containing them, so that the users could tell us which filesystems might need special handling. > One final nit: It's possible for someone to alter the data sectors > directly, without mounting the filesystem. This is sufficiently perverse > that we probably shouldn't worry about it. Agreed. Greetings, Rafael - 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/
