Hi Chris,
It sounds like a reasonable plan to me.
At first glance, I would say that your #magmaThenFilesystem approach sounds like a better way to go. For sure we need to have the file system copy as a backup, but it seems to me that if we are going to use Magma, then we should just go ahead and use it. Otherwise we would be likely to invite all of the usual problems with keeping multiple levels of "cache" in sync.
Dave
Hi Levente and David (cc:box-admins). I wanted to see if you have any suggestions or feedback for my plan to upgrade the our source.squeak.org SqueakSource instance. My goals are:
- upgrade the image to latest trunk, and VM to latest 32-bit Spur. - get it out of the chroot environment and running in the normal
environment on box4 - restore the 'mc history' and 'mc origin' functions in the image, permanently this time - ability to connect to the server image via RFB instead of having to kill and restart it - to improve the speed, scalability and reliability
As you know, our SqueakSource codebase is self-managed at http://source.squeak.org/ss. I'm currently testing the code via my own personal SqueakSource server on my LAN with a new subclass of SSStorage, called SSCompositeStorage. The CompositeStorage lets us have multiple storage back-ends attached to one server. This allows two new intermediate configurations between a 100% filesystem-only backend and a 100% Magma-only backend:
#filesystemThenMagma -- reads from the filesystem, foreground
saves to the filesystem, background saves to Magma
#magmaThenFilesystem -- reads from Magma, foreground saves to
Magma, background saves to the filesystem.
I think the former is more conservative while the latter should be better-performing (although I still plan to do some loading benchmarks). For either configuration, the Magma component enables the history on MCDefinitions.
The MagmaSession running inside the server image will require a larger memory footprint for the image.
What do you think?
Thanks, Chris