u9fs(4) [plan9 man page]

U9FS(4) 						     Kernel Interfaces Manual							   U9FS(4)

NAME

       u9fs - serve 9P from Unix

SYNOPSIS

       u9fs [ directory ]

DESCRIPTION

       U9fs  is not a Plan 9 program.  Instead it is a program that serves Unix files to Plan 9 machines using the 9P protocol (see intro(5)).	It
       is to be invoked on a Unix machine by inetd with its standard input, output, and error connected to a network connection, typically TCP	on
       an  Ethernet.   It runs as user root and multiplexes access to multiple Plan 9 clients over the single wire.  It simulates Unix permissions
       itself by assuming Plan 9 uids match Unix login names.

       If a directory is specified u9fs first does a Unix chroot system call to that directory.

       Plan 9 calls this service 9fs with TCP service number 564 on the Ethernet.  Set up this way on a machine called, say, kremvax, u9fs may	be
       connected to the name space of a Plan 9 process by

	      9fs kremvax

       Due  to	a bug in some versions of the IP software, some systems will not accept the service name 9fs, thinking it a service number because
       of the initial digit.  If so, run the service as u9fs or 564 and do the srv and mount by hand:

	      srv tcp!kremvax!u9fs
	      mount -c /srv/tcp!kremvax!u9fs /n/kremvax

       For more information on this procedure, see srv(4) and bind(1).

       U9fs serves the entire file system of the Unix machine.	It forbids access to devices because the program is single-threaded and may  block
       unpredictably.	Using  the attach specifier device connects to a file system identical to the usual system except it permits device access
       (and may block unpredictably):

	      srv tcp!kremvax!9fs
	      mount -c /srv/tcp!kremvax!9fs /n/kremvax device

       (The 9fs command does not accept an attach specifier.)  Even so, device access may produce unpredictable results if the block size  of  the
       device is greater than 8192, the maximum data size of a 9P message.

       The  source to u9fs is in the Plan 9 directory /sys/src/cmd/unix/u9fs.  To install u9fs on a Unix system, copy the source to a directory on
       that system.  Edit the makefile to set LOG to a proper place for a log file and to set the compile-time configuration correctly.  Then com-
       pile with an ANSI C compiler and install in /usr/etc/u9fs.  Install this line in inetd.conf:

	      9fs     stream  tcp     nowait  root   /usr/etc/u9fs   u9fs

       and this in services:

	      9fs     564/tcp	    9fs  # Plan 9 fs

SOURCE

       /sys/src/cmd/unix/u9fs

DIAGNOSTICS

       Problems are reported to /tmp/u9fs.log.	A compile-time flag enables chatty debugging.

SEE ALSO

       bind(1), srv(4), ip(3), nfsserver(8)

BUGS

       The implementation of devices is unsatisfactory.

																	   U9FS(4)

FS(4)							     Kernel Interfaces Manual							     FS(4)

NAME

       fs - file server, dump

SYNOPSIS

       none

DESCRIPTION

       The  file  server  is  the main file system for Plan 9.	It is a stand-alone system that runs on a separate computer.  It serves the Plan 9
       protocol on a variety of networks including Datakit/URP, Ethernet IL/IP and Cyclone fiber direct connections.  The name of  the	main  file
       server at Murray Hill is bootes.

       The  file  server  normally  requires all users except to provide authentication tickets on each attach(5).  This can be disabled using the
       noauth configuration command (see fsconfig(8)).

       The user none is always allowed to attach to bootes without authentication but has minimal permissions.

       Bootes maintains three file systems on a combination of disks and write-once-read-many (WORM) magneto-optical disks.

       other  is a simple disk-based file system similar to kfs(4).

       main   is a worm-based file system with a disk-based look-aside cache.  The disk cache holds modified worm blocks to  overcome  the  write-
	      once  property of the worm.  The cache also holds recently accessed non-modified blocks to speed up the effective access time of the
	      worm.  Occasionally (usually daily at 5AM) the modified blocks in the disk cache are dumped.  At this time, traffic to the file sys-
	      tem  is  halted and the modified blocks are relabeled to the unwritten portion of the worm.  After the dump, the file system traffic
	      is continued and the relabeled blocks are copied to the worm by a background process.

       dump   Each time the main file system is dumped, its root is appended to a subdirectory of the dump file system.  Since the dump file  sys-
	      tem  is  not  mirrored  with  a disk cache, it is read-only.  The name of the newly added root is created from the date of the dump:
	      /yyyy/mmdds.  Here yyyy is the full year, mm is the month number, dd is the day number and s is a sequence number if more  than  one
	      dump is done in a day.  For the first dump, s is null.  For the subsequent dumps s is 1, 2, 3, etc.

	      The  root  of the main file system that is frozen on the first dump of March 1, 1992 will be named /1992/0301/ in the dump file sys-
	      tem.

EXAMPLES

       Place the root of the dump file system on /n/dump and show the modified times of the MIPS C compiler over all dumps in February, 1992:

	      9fs dump
	      ls -l /n/dump/1992/02??/mips/bin/vc

       To get only one line of output for each version of the compiler:

	      ls -lp /n/dump/1992/02??/mips/bin/vc | uniq

       Make the other file system available in directory /n/bootesother:

	      mount -c /srv/boot /n/bootesother other

SOURCE

       /sys/src/fs

SEE ALSO

       yesterday(1), srv(4), fs(8)
       Sean Quinlan, ``A Cached WORM File System'', Software - Practice and Experience, December, 1991

																	     FS(4)