On Út 14-03-06 22:13:02, Rafael J. Wysocki wrote:
> Hi,
>
> 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?
> > 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.)
Pavel
--
14: {
