Hi. On Fri, 2007-04-27 at 09:50 +0300, Pekka J Enberg wrote: > On Fri, 27 Apr 2007, Nigel Cunningham wrote: > > Sorry Pekka, but that's just broken. > > It certainly isn't. > > On Fri, 27 Apr 2007, Nigel Cunningham wrote: > > It implies firstly that we tell all userspace programs "I'm sorry, but > > I'm suspending at the moment. Can you tip toe quietly around while I do > > it?" You can't seriously expect every userspace program to be modified > > to adjust it's behaviour according to whether we're writing a snapshot > > to disk at the moment or not. > > You don't need to modify other programs. You just need to display the > progress bar and block _user input_. I don't even claim to know X, but I > would be extremely surprised if you technically can't say "don't let > the user touch any other windows except this one." The user couldn't care > less whether tasks are frozen or not by the kernel. What matters is that > the user can't shoot himself in the foot while snapshotting.
User input doesn't account for all system activity. Think of cron jobs or user initiated jobs that may have started before the cycle began. > Furthermore, we probably do need to do other things to ensure safety, like > remounting filesystems read-only but again, this has nothing to do with > snapshotting per se. What the kernel needs to worry about is (1) providing > an atomic snapshot that is consistent and (2) resuming to that snapshot > safely. If the _user_ loses data that was generated between snapshot + > shutdown, it's absolutely no concern for the snapshot operation! Noooo! If the user looses data, the user will be concerned and we should be. I for one would do my best to avoid using software that loses my data for me. I wouldn't care if you said "Well, it's your fault. You lost the data." From my perspective as a user, I didn't lose the data, some part of the computer's OS did. > On Fri, 27 Apr 2007, Nigel Cunningham wrote: > > It also implies that we can prepare a snapshot and then happily have the > > contents of the disk change so that they don't match the superblock and > > other filesystem details we just saved in the snapshot. We can't. At > > least not without modifying all the filesystems so that (at a minimum) > > they know how to throw away all the metadata they have at resume time > > and reread it from disk. > > But you just explained how we can! We shouldn't bend over backwards for > snapshotting just because the filesystems don't currently support > something we need. Sorry, but I just don't believe filesystems should need to throw away metadata post resume. If we let data be changed after snapshotting (or ourselves cause it to be changed), we're the ones that are broken. Our snapshot is out of date and the expectations of userspace programs that were snapshotted will be out of date. Just imagine, for example, a userspace program that is snapshotted, then reads and deletes a temporary file. After the snapshot restore, it's running again. But wait, we can't read or delete the file again because it's already gone. Life just gets more complicated and confusing this way. > On Fri, 27 Apr 2007, Nigel Cunningham wrote: > > By the way, sorry. This email feels like it is pouring a lot of cold > > water on your ideas. I don't want to be negative! > > Don't worry, I am used to cold water :-). Maybe, but I'd still rather be encouraging! Nigel
signature.asc
Description: This is a digitally signed message part
