Re: Flames over -- Re: Which is simpler?

[Olivier Galibert <galibert@pobox.com>]

On Sun, Feb 19, 2006 at 08:43:44PM +0100, Pavel Machek wrote:
> Kernel can not tell the diference, and just because you don't like the
> behaviour does not mean we have to work around hardware limitation.
> 
> You deal with it. Post a patch.

It would take more than one patch, but it could be done:

Suspend time:

  1- Freeze all processes enough that no filesystem activity happens
  anymore.

  2- Do a map of the currently-opened files.  That is, for each opened
  file, find a workable path to it.  If you have the dentry, you have
  it.  Otherwise, on a filesystem that supports inodes, just
  sillyrename them to something in /.suspend.  For the non-inode
  filesystems, require not dropping the dentries for reliable suspend.
  They probably need to keep them in some form anyway for handling
  multiple opens of the same file.

  3- Sync the filesystems to the point that they're in clean state.

  4- Add the path mapping from (2) to the suspend image.

  5- Allow userspace to pick up any information it finds relevant
  about the filesystems/devices and put that info in the image too.


Resume time:

  6- Resume userspace checks the existing devices, find a mapping (or
  a lack of) using the information from (5) and the paths from (4)

  7- Rebuild the userspace from the image.

  8- Re-open/remap the files from the paths, sillyrenamed entries are
  unlinked once reopened.  Paths not found and filesystems not found
  are send to a virtual file on a virtual filesystem that just -EIOs
  or SEGVs mmaps.


Pros:
- You never lose filesystems or files, ever.  Only thing you can lose
  is processes.

- You can touch files in the suspended filesystems (device plugging,
  restart on the wrong kernel) without damage.

- You can remount the filesystems ro after 3, which allows access to
  whatever files the chrome may like.

- You only have to save the anonymous pages and the metadata.

Cons:
- Suspend may be slower since the write patterns are more dispersed
  than just swap.  OTOH, it will be no slower than sync(1).


There are probably things I haven't thought of, but I think it's the
kind of approach you need to be sure to be reliable no matter what.

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/