Re: Re: standby to disk transition

[Pavel Machek <pavel@suse.cz>]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Hi!

> > > Well, copying all the filesystems would work, as would having no
> > > filesystems at all :-) [ramdisk case]. And perhaps practical
> > > equivalent of "copy all filesystems" can be done with device mapper.
> > >
> > > [Of course, you'd have to copy all the filesystems back before doing
> > > resume].
> >
> > If we had anything like fs suspend/resume, we could handle such things.
> > We could also handle the "USB device mounted before suspend" problem
> > (I think it's related).
> 
> Well, we have bdev freezing, which I guess is what is used for fixing up raid 
> mirrors (but don't know for certain). I use it in refrigerating to get XFS to 
> really stop activity. I don't think it helps in this case though:
> 
> 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?

AFAIK, such support exists at "device mapper" level.
									Pavel
-- 
179:        alg.Mode = CipherMode.CBC;

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]