Re: Re: standby to disk transition

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Tuesday 14 March 2006 22:22, Pavel Machek wrote:
> On Út 14-03-06 22:13:02, Rafael J. Wysocki wrote:
> > On Tuesday 14 March 2006 21:33, Pavel Machek wrote:
> > > > > We need to be able to rollback the state of the filesystem in memory and on 
> > > > > disk to the point where the last checkpoint was made. Memory would be 
> > > > > straight forward if we want to do it dumbly and slowly - just reload the 
> > > > > whole check pointed image. If we want to be more efficient, we'd want to just 
> > > > > load the pages that had changed (Mark on (first) write?). But filesystems 
> > > > > seem to be a whole different story. Do any of the commonly used fses have 
> > > > > support for checkpointing and rollback back at the moment?
> > > > 
> > > > I'm not sure if we need a rollback as such.  What we need is to make sure
> > > > the filesystems state will be consistent before as well as after we have
> > > > "reloaded" the snapshot.
> > > 
> > > Even if you make sure *kernel* is consistent with changed filesystem,
> > > userland is going to be badly confused. Imagine what will happen with
> > > memory mapped files, for example. 
> > 
> > Something like what happens when you suspend with a mounted CD
> > and mmapped files from there, then you replace the CD while suspended
> > and resume.  Not a wise thing to do, but I think people will do such things
> > from time to time and we'd better be prepared to handle them nicely.
> 
> But... we can't prevent userspace from segfaulting in such case... can
> we?

If we know the filesystem is gone before the applications have a chance
to do anything, like on resume, we can.  Eventually we can just kill all of the
processes that use memory mapped files from the missing filesystem.
That would be a bit drastic, though. ;-)

> > > I'm not sure how it could work...
> > 
> > IMO memory mapped files are the most difficult problem here,
> > but the rest seems to be doable in general.
> 
> It seems to be the same problem with removable media... You could
> replace mounted CDrom while running. (Not all CDroms support door
> lock.)

Yes, but there are two distinct classes of cases:
(1) we know the media has been removed before any process tries to access it
(eg. the related bus driver detects the disconnect, like USB)
(2) we have no means to detect the removal of the media except for trying to
access it.

For the class (1) of events we can do some clean-up work,at least in principle,
and we are talking of such a case, IMO.

Greetings,
Rafael