iop.1(2)

NAME

iop - start a Galley I/O server

iop [-h] [-pi | -npi] [-sd | -nsd] [-dm | -ndm] [-ds disk_size] [-cs cache_size] [-dl debug_level]

iop starts a single Galley I/O server.

Options

-pi, -npi: Start an IOP either for private use (-pi) or for common use (-npi). A collection of private IOPs essentially functions as a parallel file system for a single user. Collision with other public and private file systems is accomplished by assigning a unique TCP/IP channel number to each user. A collection of non-private IOPs functions as a parallel file system shared by multiple users. In this case, there is a single "well-known" TCP/IP channel that all users use to communicate with the IOPs. When using Unix files as the low-level devices, collision is avoided by appending the user's Unix uid to the file name. When using raw devices, there is no built-in way to avoid collisions. One approach is to restrict raw-device access to a single user, running the IOPs setuid to that user. This same approach can be used to provide a minimal level of protection to the directory that houses the private file systems (if any).

-sd, -nsd: Use either a simulated disk or a real disk as the lowlevel device. The "real" disk may be either a Unix file or a raw device, but that choice must be compiled in (this compiled-in requirement should go away).

-dm, -ndm: These options determine whether or not the IOP will run as a daemon. That is, whether it will detach from the controlling terminal, and run independently. Unless you are debugging the IOP, there probably isn't a lot of reason to run the IOPs as non-daemons. When debugging, you may want to send output to the screen, which can't be done when the IOP is running as a daemon. Also, if you start the IOP from within dbx/gdb, you don't want it to daemonize on you, leaving you with nothing to debug.

-ds disk_size: How many disk blocks should be allocated for the file system.

-cs cache_size: How many blocks should be set aside in memory for the buffer cache.