[GE users] filesystem sharing across multiple architectures - for submission hosts

Paul Osborne P.A.Osborne at kent.ac.uk
Thu Jan 5 15:12:57 GMT 2006

    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

I have a cluster of machines all Solaris x86 and would like to be able 
to submit jobs on this cluster from another host that is a different 
architecture (Solaris sparc) that is not going to be executing any jobs

I merely want to be able to do :  qsub myjob and it goes and runs 
elsewhere. However this job must be a binary running on the cluster.

My question relates to the level of filesystem awareness that needs to 
be available from the cluster to the submission host.

For example:

on the submit host say (as an example no more) I have in my home dir a 
shell script containing:

/usr/local/bin/mybinary    --  where this binary is Solaris x86 and is
                                installed on the cluster machines - but 

                                NOT on the submission host.

The shell script is deliberate as I want to set up wrappers for jobs.

If I then do:  qsub ~/myscript   (which is the one above),  is the qsub 
going to submit the script and then that script will call the binary as 
installed on the cluster,  or is it going to attempt to call the binary
off the submission host and pass that to the cluster?

I am hoping that the former is true as then I do not need to worry about 
having filesystems of binaries that are not going to work available to 
the users of the submission host (should they try and run them by hand) 
and also I then have less crossmounted filesystems between hosts and so 
things are a little less complicated from a systems management point of 

Thanks for your time.


To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list