ATTACH(5) File Formats Manual ATTACH(5)NAME
attach, session, nop - messages to initiate activity
SYNOPSIS
Tnop tag[2]
Rnop tag[2]
Tsession tag[2] chal[8]
Rsession tag[2] chal[8] authid[28] authdom[48]
Tattach tag[2] fid[2] uid[28] aname[28] ticket[72] auth[13]
Rattach tag[2] fid[2] qid[8] rauth[13]
DESCRIPTION
The nop request does nothing overt but may be used to synchronize the channel between two service hosts initially.
The session request is used to initialize a connection between a client and a server. All outstanding I/O on the connection is aborted.
The set of messages between session requests is called a session. The host's user name (authid) and its authentication domain (authdom)
identify the key to be used when authenticating to this host. The exchanged challenges (chal) are used in the authentication algorithm.
If authid is a null string no authentication is performed in this session.
The tag should be NOTAG (value 0xFFFF) for a nop or session message.
The attach message serves as a fresh introduction from a user on the client machine to a server. The message identifies the user (uid) and
may select the file tree to access (aname). The ticket and auth arguments contains authorization data derived from the exchanged chal-
lenges of the session message; see auth(6).
As a result of the attach transaction, the client will have a connection to the root directory of the desired file tree, represented by
fid. An error is returned if fid is already in use. The server's idea of the root of the file tree is represented by the returned qid.
ENTRY POINTS
An attach transaction will be generated for kernel devices (see intro(3)) when a system call evaluates a file name beginning with Pipe(2)
generates an attach on the kernel device pipe(3). The mount system call (see bind(2)) generates an attach messages to the remote file
server. When the kernel boots, an attach is made to the root device, root(3), and then an attach is made to the requested file server
machine.
SEE ALSO auth(6)ATTACH(5)
Check Out this Related Man Page
mount.diod(8) diod mount.diod(8)NAME
mount.diod - mount diod file systems
SYNOPSIS
mount.diod [OPTIONS] host[:aname] dir [-o options]
DESCRIPTION
mount.diod is the mount utility for the distributed I/O daemon, which is an I/O forwarding service for Linux clusters built upon the Linux
9p file system.
mount.diod performs two main tasks: 1) connect and authenticate to the diod server, and 2) issue the mount(2) system call with appropriate
mount options.
Authentication with the diod server takes place in user space. The connected (and authenticated) file descriptor is passed as a mount
option to the kernel 9p file system
This command requires root to execute the mount(2) system call.
The 9p file system must support the 9P2000.L protocol variant, e.g. kernel 2.6.38 or above.
The host portion of the mount spec may optionally be supplied in hostlist format, e.g. host1,host2,host3:aname or host[1-3]:aname, in which
case hosts are tried in order until a successful connection is obtained. Post-connect mount errors are immediately fatal.
If the host portion of the mount spec begins with a forward-slash (/), it refers to the path to a UNIX domain socket.
COMMAND LINE OPTIONS -f, --fake-mount
Do everything except the mount system call.
-n, --no-mtab
Do not update the system mtab.
-v, --verbose
Set verbose mode.
-o, --options opt[,opt,...]
Set mount options (see below).
MOUNT OPTIONS
The following file system specific mount options are handled by mount.diod.
aname=name
The aname is the path of the exported file system on the server. It can be specified in the mount spec in host:aname format like
NFS, or it can be specified with this option. diod will not allow an attach to an empty aname. diod has a built-in synthetic con-
trol file system that can be mounted with aname of ctl.
uname=name
The user name to authenticate to the diod server. The default is uname=root.
access=mode
Select the access mode. access=user (default) causes the mount to support multiple users, and requires root authentication.
access=<uid> restricts access at the client to only the specified user.
port=n Connect to the diod server on the specified port. The default is the IANA-assigned 9pfs port 564.
trans=name
Select a transport. mount.diod only supports trans=fd because of its strategy for authentication.
rfdno=n,wfdno=n
The file descriptor for reading and writing with trans=fd. If set, mount.diod assumes this file descriptor is already connected to
a diod server and ignores host in the device specification, and the port=n option.
msize=n
The msize is the max 9P packet payload size. The default is 65512 (65536-24)
version=name
Select 9P protocol version. diod only supports 9p2000.L.
cache=mode
Specify a caching policy. By default, no caches are used. If cache=loose, no attempts are made at consistency. This mode is
intended for exclusive, read-only mounts. If cache=fscache, use FS-Cache for a persistent, read-only cache backend.
cachetag
In the context of cache=fscache, select the cache tag to use for this session. Cache tags for existing cache sessions are listed in
/sys/fs/9p/caches.
nodevmap
Do not map special files. Represent them as normal files. This can be used to share devices/named pipes/sockets between hosts.
debug=n
Specifies debug level for the kernel 9p module. The debug level is a bitmask.
0x01 = display verbose error messages
0x02 = developer debug (DEBUG_CURRENT)
0x04 = display 9p trace
0x08 = display VFS trace
0x10 = display Marshalling debug
0x20 = display RPC debug
0x40 = display transport debug
0x80 = display allocation debug
0x100 = display protocol message debug
0x200 = display Fid debug
0x400 = display packet debug
0x800 = display fscache tracing debug
The debug level is global, i.e. it applies to all 9P file systems and it remains set after the file system is unmounted. The
default is debug=0.
SEE ALSO
diod (8)
diod-1.0.13 2012-05-22 mount.diod(8)