> The files/code etc don't necessarily have to be on another machine. If
> you have a group of machines with NFS mounts for all significant file
> systems then the process can just be loaded from the file with the same
> name on the destination machine. For shared libraries IFF all machines
> have the same versions installed then loading from the local libraries on
> the hard drive instead of over the network would be a huge win. With the
> way sym-links are used in linux such as the following: lrwxrwxrwx 1 root
> root 13 Jun 15 01:09 libc.so.6 -> libc-2.0.4.so
> An application could just load to /lib/libc.so.6 and it could then move
> to any machine with a file named /lib/libc-2.0.4.so. If that file isn't
> available then you could refuse to allow it to migrate to that machine.
>
> As for user files if all machines had the same /home and /var/spool/mail
> directories then the same scheme could work. A potentially significant
> problem is /tmp. For example when you run a compiler which has cpp writing
> to /tmp/something which the main compiler will expect to read then it will
> be difficult to migrate things (NFS mounted /tmp is a bad thing).
> The same thing would work if you had a cluster of machines with the
> omirrd running (when omirrd gets fixed and is runnable again).
I don't intend the machines to have any special arrangement for the
migration to occur. I want to try to use migration for the very simple
case where you have 10 independent machines on a net, only 1 is being used
by say 15 users running pine to read mail. I want to get some pines to go
somewhere else.
Maybe the pine example is not very good, and I can see people flaming me
on that, but you get the picture.
> I think it might be easier to just move the data across as one operation
> and have the executable loaded from file on the target machine. Moving a
> page at a time will make VM management very tricky.
On Fred Douglis' thesis on process migration in Sprite, he says (actually
it's a reference to other paper) that transfering on demand saves from 20%
to 95% of all memory transfer, as usually you are going to transfer lot's
of unused init code, for example.
> I suggest that you just not support shared memory. If the process has
> shared memory then it's not distributable. In version 2.0 after you've
> graduated you can support this. ;-)
That's something I've been thinking. Also, processes that access hardware
directly (rare but existing) can't be migrated, anyway... :)
> What do you really have to redirect apart from signals and access to
> /dev/*?
Well, considering the filesystems can be very different from station to
station, all file ops, for instance.
> That depends, is "hello world" statically linked? ;-)
:) Maybe I'll demonstrate my project to the referees (is that the right
word?) using a simple assembly program, statically linked, that closes all
files, blocks all signals, sits on a loop for 5 min and then exits :)).
[]!
Fabio
( Fabio Olive Leite leitinho@akira.ucpel.tche.br )
( Computing Science Student http://akira.ucpel.tche.br/~leitinho/ )
( )
( LOADLIN.EXE: The best Windows95 application. [Debian GNU/Linux] )