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;
