Every now and then, I get the urge to think about
some fun future architectural stuff for plex86.
So here's a very abstract view of a potential
disk access model.
Ultimately it will be very useful to have as
an option, some kind of journaled disk access,
so that we can "roll-back" changes or at least
decide not to commit recent changes to a
disk drive.
Periodically, the user could commit recent
changes to the disk, and these changes would
become permanent. So we might view this as:
COMMIT POINT 0
disk writes
disk writes
disk writes
...
disk writes
COMMIT POINT 1
disk writes
disk writes
disk writes
...
disk writes
COMMIT POINT 2
A user would fire up plex86, and it would begin with a
disk image file or partition which represents a commit point X.
All disk writes thereafter, are stored in some kind of cache.
Future reads look in the cache first, then the disk.
If the user is running in "read-only" mode, then the cache
is automatically dumped (ignored) when they quit plex86.
If the user is running in "read-write" mode, then the cache
is written to the disk, only if the user requests a disk commit.
Having commit points also helps us implement another mechanism;
offering multiple reader capability. To keep things coherent,
there can only be one disk writer. But a user may want to use
one image file or partition to run multiple VMs, each which
does it's own disk writing.
If we define RO access, as starting at a commit point, and
having it's own write cache which is ignored upon exit, then
perhaps we could let multiple readers attach to the disk.
I'd imagine we can't let a commit happen, until all readers
unattach though.
Any thoughts on this stuff? We also need to think in terms
of allowing loopback mounting of disk images.
-Kevin
