Subject: RE: [PATCH] Copy on write (persistent disk) support for MOL
From: Michael Clark (michael@metaparadigm.com)
Date: Fri Feb 09 2001 - 09:57:54 MST
Hi Geoff,
> I tried this out and it seems to work great (seeing a working MacOS
> system up in a second is
> amazing), but after thinking about it I have a few questions:
>
> 1) without an ability to commit changes from the overlay file, all
> worked saved to the overlay
> is "lost", right?
Yes (which is great if that's what you want - for instance in a lab environment,
which is where I'm think of using it). It's best used with all work data stored
on network shares.
I'll put together the commit utility when I have time over the next couple of
days.
> 2) I'm not sure I understand the networked drive argument. Say I'm
> editing a file and save it
> on a network share, and then MacOS crashes. When I restore the
> session, I have the pre-edited
> file in memory, so I need to reload the file from disk, otherwise
> I'll have lost my changes.
> This suggests that is it rather dangerous to have files open in your
> saved state: your saved
> state should probably just have the OS and applications loaded, but
> not any work files open.
Yes. You also can't have any network shares mapped either - as all network
connections will be closed and will vanish when you resume. I'm currently
working on a Mac-side app that will restore network connections and copy certain
preferences from a network share on resume - and likewise will copy them back on
shutdown.
> 3) what happens with session_readonly no and blkdev -cow?
If you suspend, you will have an invalid session file as the block device won't
have changed (all changes will be in the overlay files) - you would need to be
able to commit the overlay file changes for a resume to work.
> Does a new overlay file get created?
Yes, the existing overlay file is truncated when mol starts. It would be very
easy to add an option to not truncate the overlay file on startup (but this of
course would invalidate the readonly session file).
At the moment it only makes sense to use both options together - maybe I could
make it a little simpler and roll the functionality into a single option
'copy_on_write' which would make all r/w devices cow and the session file read
only.
Your comments gave me a couple of new ideas I could implement:
* atomic session saving (the mol session file is currently modified throughout
the session and only becomes a valid resume image after saving a session and
committing block device changes). My currently implementation of
'session_readonly' just changes the mmap MAP_SHARED option to MAP_PRIVATE (cow)
(mol mmaps memory from the session file) - atomic session saving would basically
open the session readonly with MAP_PRIVATE, and would write memory out to a new
file on session save, then moving it over the original. This would make session
saving a little slower.
* commit block device changes on session save.
~mc
This archive was generated by hypermail 2a24 : Fri Feb 09 2001 - 09:55:30 MST