OS Suspend to disk (Google Summer of Code)

[John Baldwin]

On Thursday 03 April 2008 07:43:15 pm Andrew Pilloud wrote:
> John Baldwin wrote:
> > Hmm, the idea of reading the saved image in during early boot is a bit
> > different.  One thing to note is that / does have to be mounted for rc
> > scripts to run (so at least one filesystem will already be mounted).  One
> > thing that might make it easier though, is to just require a separate
> > disk partition (like swap, but a dedicated one, not reusing swap) to dump
> > the RAM image into.  Later on you could extend it to use a pre-allocated
> > file on a filesystem perhaps, but using a dedicated partition for now
> > might reduce the work needed.  I think if you can dump all of RAM to a
> > suspend partition then it actually is not too hard to make the loader
> > just read that into RAM with some sort of header to give an entry point
> > (and to validate it).
> >
> > Some things that would be really nice for S4 suspend though would be to
> > have the system try to quiesce things more during suspend than it does
> > now.  For example, it would be nice if suspend would flush pending writes
> > to disk and possibly mark filesystems as clean before actually going to
> > sleep to minimize data loss (this would be useful even for S1 or S3 if
> > the battery runs out while suspended).
>
> Thanks for the advice. I don't think / being mounted read only will be a
> problem. As long as the disk is not modified everything should be fine.
> A dedicated partition would make things easier, especially with resuming
> in the boot loader.

I think making things easier is good for a first pass to make it more feasible 
of getting something working during the summer.

> There seem to be different advantages to both ways of resuming the
> system. Microsoft products resume in the boot loader, and Linux in a
> script just after the kernel loads. This seems like something that could
> turn into a bikeshed debate rather quickly. I think the best way to
> determine which is better is to implement them both.

Both is probably fine.  I would aim to make things as simple as possible at 
first though.

> As for the file systems, I don't really know what more you can do to
> quiesce the system then is already being done. When you suspend, the
> script rc.suspend is suppose to run. That script runs sync, which should
> take care of flushing pending disk writes. I don't know if marking a
> file system clean is wise or even possible without completely
> un-mounting it.

It's quite possible.  Filesystems just have a dirty bit usually in a 
superblock-type thing that you can clear if all pending writes are flushed.  
Something like this would need to be done via a kernel event I think though 
rather than just calling sync from userland.

-- 
John Baldwin