828 lines
15 KiB
HTML
828 lines
15 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>openMosix General Instructions</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The openMosix HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Distribution specific installations"
|
|
HREF="distributions.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Getting openMosix"
|
|
HREF="x326.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Red Hat and openMosix"
|
|
HREF="x424.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The openMosix HOWTO: </TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x326.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 4. Distribution specific installations</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x424.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN332"
|
|
></A
|
|
>4.4. openMosix General Instructions</H1
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN334"
|
|
></A
|
|
>4.4.1. Kernel Compilation</H2
|
|
><P
|
|
> Always use pure vanilla kernel-sources from <A
|
|
HREF="http://www.kernel.org/"
|
|
TARGET="_top"
|
|
><I
|
|
CLASS="CITETITLE"
|
|
>http://www.kernel.org/</I
|
|
></A
|
|
> to compile an
|
|
openMosix kernel! Please be kind enough to download the kernel using a
|
|
mirror near to you and always try and download patches to the latest
|
|
kernel sources you do have instead of downloading the whole
|
|
thing. This is going to be much appreciated by the Linux community and
|
|
will greatly increase your geeky Karma ;-)
|
|
|
|
Be sure to use the right openMosix patch depending on the
|
|
kernel-version. At the moment I write this, the latest 2.4 kernel is
|
|
2.4.20 so you should download the openMosix-2.4.20-x.gz patch, where
|
|
the "x" stands for the patch revision (ie: the greater the revision
|
|
number, the most recent it is).
|
|
|
|
Do not use the kernel that comes with any Linux-distribution: it won't
|
|
work. These kernel sources get heavily patched by the
|
|
distribution-makers so, applying the openMosix patch to such a kernel
|
|
is going to fail for sure! Been there, done that: trust me ;-)</P
|
|
><P
|
|
>Download the actual version of the openMosix patch and move it in your
|
|
kernel-source directory (e.g. /usr/src/linux-2.4.20). If your
|
|
kernel-source directory is other than
|
|
"/usr/src/linux-[version_number]" at least the creation of a symbolic
|
|
link to "/usr/src/linux-[version_number]" is required.
|
|
|
|
Supposing you're the root user and you've downloaded the gzipped patch
|
|
file in your home directory, apply the patch using (guess what?) the
|
|
patch utility:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
|
|
cd /usr/src/linux-2.4.20
|
|
zcat openMosix-2.4.20-2.gz | patch -Np1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
In the rare case you don't have "zcat" on your system, do:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
|
|
cd /usr/src/linux-2.4.20
|
|
gunzip openMosix-2.4.20-2.gz
|
|
cat openMosix-2.4.20-2 | patch -Np1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
If the even more weird case you don't have a "cat" on your system (!),
|
|
do:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
|
|
cd /usr/src/linux-2.4.20
|
|
gunzip openMosix-2.4.20-2.gz
|
|
patch -Np1 < openMosix-2.4.20-2</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
|
|
The "patch" command should now display a list of patched files from
|
|
the kernel-sources.
|
|
|
|
If you feel adventurous enough, enable the openMosix related options
|
|
in the kernel-configuration file, e.g.
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>...
|
|
CONFIG_MOSIX=y
|
|
# CONFIG_MOSIX_TOPOLOGY is not set
|
|
CONFIG_MOSIX_UDB=y
|
|
# CONFIG_MOSIX_DEBUG is not set
|
|
# CONFIG_MOSIX_CHEAT_MIGSELF is not set
|
|
CONFIG_MOSIX_WEEEEEEEEE=y
|
|
CONFIG_MOSIX_DIAG=y
|
|
CONFIG_MOSIX_SECUREPORTS=y
|
|
CONFIG_MOSIX_DISCLOSURE=3
|
|
CONFIG_QKERNEL_EXT=y
|
|
CONFIG_MOSIX_DFSA=y
|
|
CONFIG_MOSIX_FS=y
|
|
CONFIG_MOSIX_PIPE_EXCEPTIONS=y
|
|
CONFIG_QOS_JID=y
|
|
...</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
However, it's going to be pretty much easier if you configure the
|
|
above options using one of the Linux-kernel configuration tools:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>make config | menuconfig | xconfig</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
The above means you have to choose one of "config", "menuconfig", and
|
|
"xconfig". It's a matter of taste. By the way, "config" is going to
|
|
work on any system; "menuconfig" needs the curses libraries installed
|
|
while "xconfig" needs an installed X-window environment plus the
|
|
TCL/TK libraries and interpreters.</P
|
|
><P
|
|
>Now compile it with:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>make dep bzImage modules modules_install</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
After compilation install the new kernel with the openMosix options
|
|
within you boot-loader; e.g. insert an entry for the new kernel in
|
|
/etc/lilo.conf and run lilo after that.</P
|
|
><P
|
|
>Reboot and your openMosix-cluster-node is up!</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN348"
|
|
></A
|
|
>4.4.2. Syntax of the /etc/openmosix.map file</H2
|
|
><P
|
|
>Before starting openMosix, there has to be an /etc/openmosix.map
|
|
configuration file which must be the same on each node. </P
|
|
><P
|
|
>The standard is now /etc/openmosix.map, /etc/mosix.map and /etc/hpc.map are old
|
|
standards, but the CVS-version of the
|
|
tools is backwards compatible and looks for /etc/openmosix.map,
|
|
/etc/mosix.map and /etc/hpc.map (in that order). </P
|
|
><P
|
|
>The
|
|
openmosix.map file contains three space separated fields:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>openMosix-Node_ID IP-Address(or hostname) Range-size</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
An example openmosix.map file could look like this:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>1 node1 1
|
|
2 node2 1
|
|
3 node3 1
|
|
4 node4 1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
or
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>1 192.168.1.1 1
|
|
2 192.168.1.2 1
|
|
3 192.168.1.3 1
|
|
4 192.168.1.4 1</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
or with the help of the range-size both of the above examples equal to:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>1 192.168.1.1 4</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
openMosix "counts-up" the last byte of the ip-address of the node
|
|
according to its openMosix-Node_ID. Of course, if you use a
|
|
range-size greater than 1 you have to use ip-addresses instead of
|
|
hostnames.</P
|
|
><P
|
|
>If a node has more than one network-interface it can be configured
|
|
with the ALIAS option in the range-size field (which equals to setting
|
|
the range-size to 0) e.g.
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>1 192.168.1.1 1
|
|
2 192.168.1.2 1
|
|
3 192.168.1.3 1
|
|
4 192.168.1.4 1
|
|
4 192.168.10.10 ALIAS</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
Here the node with the openMosix-Node_ID 4 has two network-interfaces
|
|
(192.168.1.4 + 192.168.10.10) which are both visible to openMosix.</P
|
|
><P
|
|
><EM
|
|
>Always be sure to run the same openMosix version AND configuration on each
|
|
of your Cluster's nodes!</EM
|
|
></P
|
|
><P
|
|
>Start openMosix with the "setpe" utility on each node :
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>setpe -w -f /etc/openmosix.map</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
Execute this command (which will be described later on in this HOWTO)
|
|
on every node in your openMosix cluster.</P
|
|
><P
|
|
>Alternatively, you can grab the "openmosix" script which can be found
|
|
in the scripts directory of the userspace-tools, copy it to the
|
|
/etc/init.d directory, chmod 0755 it, then use the following commands
|
|
as root:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>/etc/init.d/openmosix stop
|
|
/etc/init.d/openmosix start
|
|
/etc/init.d/openmosix restart</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Installation is finished now: the cluster is up and running :)</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN366"
|
|
></A
|
|
>4.4.3. oMFS</H2
|
|
><P
|
|
>First of all, the CONFIG_MOSIX_FS option in the kernel configuration
|
|
has to be enabled. If the current kernel was compiled without this
|
|
option, then recompilation with this option enabled is required.</P
|
|
><P
|
|
> Also
|
|
the UIDs (User IDs) and GIDs (Group IDs) on each of the clusters'
|
|
nodes file-systems must be the same. You might want to accomplish this using
|
|
openldap. The CONFIG_MOSIX_DFSA option in
|
|
the kernel is optional but of course required if DFSA should be used.
|
|
To mount oMFS on the cluster there has to be an additional fstab-entry
|
|
on each node's /etc/fstab.</P
|
|
><P
|
|
>in order to have DFSA enabled:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>mfs_mnt /mfs mfs dfsa=1 0 0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
in order to have DFSA disabled:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>mfs_mnt /mfs mfs dfsa=0 0 0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
the syntax of this fstab-entry is:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>[device_name] [mount_point] mfs defaults 0 0</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
After mounting the /mfs mount-point on each node, each node's
|
|
file-system is going to be accessible through the
|
|
/mfs/[openMosix-Node_ID]/ directories.</P
|
|
><P
|
|
>With the help of some symbolic links all cluster-nodes can access the same
|
|
data e.g. /work on node1
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>on node2 : ln -s /mfs/1/work /work
|
|
on node3 : ln -s /mfs/1/work /work
|
|
on node3 : ln -s /mfs/1/work /work
|
|
...</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
Now every node can read+write from and to /work !</P
|
|
><P
|
|
> The following special files are excluded from the oMFS:
|
|
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>the /proc directory</P
|
|
></LI
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>special files which are not regular-files,
|
|
directories or symbolic links (e.g. /dev/hda1) </P
|
|
></LI
|
|
></UL
|
|
></P
|
|
><P
|
|
>Creating links like:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>ln -s /mfs/1/mfs/1/usr </PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
or
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="PROGRAMLISTING"
|
|
>ln -s /mfs/1/mfs/3/usr</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
is invalid.</P
|
|
><P
|
|
>The following system calls are supported without sending the migrated
|
|
process (which executes this call on its home (remote) node) going
|
|
back to its home node:</P
|
|
><P
|
|
>read, readv, write, writev, readahead, lseek, llseek, open, creat,
|
|
close, dup, dup2, fcntl/fcntl64, getdents, getdents64, old_readdir,
|
|
fsync, fdatasync, chdir, fchdir, getcwd, stat, stat64, newstat, lstat,
|
|
lstat64, newlstat, fstat, fstat64, newfstat, access, truncate,
|
|
truncate64, ftruncate, ftruncate64, chmod, chown, chown16, lchown,
|
|
lchown16, fchmod, fchown, fchown16, utime, utimes, symlink, readlink,
|
|
mkdir, rmdir, link, unlink, rename</P
|
|
><P
|
|
>Here are situations when system calls on DFSA mounted file-systems may not
|
|
work:
|
|
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>different mfs/dfsa configuration on the
|
|
cluster-nodes</P
|
|
></LI
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>dup2 if the second file-pointer is
|
|
non-DFSA</P
|
|
></LI
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>chdir/fchdir if the parent dir is
|
|
non-DFSA</P
|
|
></LI
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>pathnames that leave the
|
|
DFSA-filesystem</P
|
|
></LI
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>when the process which executes the system-call is
|
|
being traced</P
|
|
></LI
|
|
><LI
|
|
STYLE="list-style-type: opencircle"
|
|
><P
|
|
>if there are pending requests for the process which
|
|
executes the system-call</P
|
|
></LI
|
|
></UL
|
|
></P
|
|
><P
|
|
>Next to the /mfs/1/ /mfs/2/ and so on files you will find some other
|
|
directories as well.</P
|
|
><DIV
|
|
CLASS="TABLE"
|
|
><A
|
|
NAME="AEN402"
|
|
></A
|
|
><P
|
|
><B
|
|
>Table 4-1. Other Directories</B
|
|
></P
|
|
><TABLE
|
|
BORDER="1"
|
|
CLASS="CALSTABLE"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>/mfs/here</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>The current node where your process runs</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>/mfs/home</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>Your home node</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>/mfs/magic</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>The current node when used by the "creat" system call (or
|
|
an "open" with the "O_CREAT" option) - otherwise, the last node on
|
|
which an oMFS magical file was successfully created (this is very
|
|
useful for creating temporary-files, then immediately unlinking
|
|
them)
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>/mfs/lastexec</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>The node on which the process last issued a successful
|
|
"execve" system-call.
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>/mfs/selected</TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
>The node you selected by either your process itself or one
|
|
of its ancestor's (before forking this process), writing a number
|
|
into "/proc/self/selected".
|
|
</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Note that these magic files are all ``per process''. That is their
|
|
content is dependent upon which process opens them.</P
|
|
><P
|
|
>A last not about openMFS is that there are versions around that return
|
|
faultive results when you run <SPAN
|
|
CLASS="QUOTE"
|
|
>"df"</SPAN
|
|
> on those filesystems.
|
|
Don't be surpised if you suddenlty have about 1.3 TB available on those
|
|
systems.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x326.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x424.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Getting openMosix</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="distributions.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Red Hat and openMosix</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |