9p.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277
  1. .. SPDX-License-Identifier: GPL-2.0
  2. =======================================
  3. v9fs: Plan 9 Resource Sharing for Linux
  4. =======================================
  5. About
  6. =====
  7. v9fs is a Unix implementation of the Plan 9 9p remote filesystem protocol.
  8. This software was originally developed by Ron Minnich <rminnich@sandia.gov>
  9. and Maya Gokhale. Additional development by Greg Watson
  10. <gwatson@lanl.gov> and most recently Eric Van Hensbergen
  11. <ericvh@gmail.com>, Latchesar Ionkov <lucho@ionkov.net> and Russ Cox
  12. <rsc@swtch.com>.
  13. The best detailed explanation of the Linux implementation and applications of
  14. the 9p client is available in the form of a USENIX paper:
  15. https://www.usenix.org/events/usenix05/tech/freenix/hensbergen.html
  16. Other applications are described in the following papers:
  17. * XCPU & Clustering
  18. http://xcpu.org/papers/xcpu-talk.pdf
  19. * KVMFS: control file system for KVM
  20. http://xcpu.org/papers/kvmfs.pdf
  21. * CellFS: A New Programming Model for the Cell BE
  22. http://xcpu.org/papers/cellfs-talk.pdf
  23. * PROSE I/O: Using 9p to enable Application Partitions
  24. http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
  25. * VirtFS: A Virtualization Aware File System pass-through
  26. https://kernel.org/doc/ols/2010/ols2010-pages-109-120.pdf
  27. Usage
  28. =====
  29. For remote file server::
  30. mount -t 9p 10.10.1.2 /mnt/9
  31. For Plan 9 From User Space applications (http://swtch.com/plan9)::
  32. mount -t 9p `namespace`/acme /mnt/9 -o trans=unix,uname=$USER
  33. For server running on QEMU host with virtio transport::
  34. mount -t 9p -o trans=virtio <mount_tag> /mnt/9
  35. where mount_tag is the tag generated by the server to each of the exported
  36. mount points. Each 9P export is seen by the client as a virtio device with an
  37. associated "mount_tag" property. Available mount tags can be
  38. seen by reading /sys/bus/virtio/drivers/9pnet_virtio/virtio<n>/mount_tag files.
  39. USBG Usage
  40. ==========
  41. To mount a 9p FS on a USB Host accessible via the gadget at runtime::
  42. mount -t 9p -o trans=usbg,aname=/path/to/fs <device> /mnt/9
  43. To mount a 9p FS on a USB Host accessible via the gadget as root filesystem::
  44. root=<device> rootfstype=9p rootflags=trans=usbg,cache=loose,uname=root,access=0,dfltuid=0,dfltgid=0,aname=/path/to/rootfs
  45. where <device> is the tag associated by the usb gadget transport.
  46. It is defined by the configfs instance name.
  47. USBG Example
  48. ============
  49. The USB host exports a filesystem, while the gadget on the USB device
  50. side makes it mountable.
  51. Diod (9pfs server) and the forwarder are on the development host, where
  52. the root filesystem is actually stored. The gadget is initialized during
  53. boot (or later) on the embedded board. Then the forwarder will find it
  54. on the USB bus and start forwarding requests.
  55. In this case the 9p requests come from the device and are handled by the
  56. host. The reason is that USB device ports are normally not available on
  57. PCs, so a connection in the other direction would not work.
  58. When using the usbg transport, for now there is no native usb host
  59. service capable to handle the requests from the gadget driver. For
  60. this we have to use the extra python tool p9_fwd.py from tools/usb.
  61. Just start the 9pfs capable network server like diod/nfs-ganesha e.g.::
  62. $ diod -f -n -d 0 -S -l 0.0.0.0:9999 -e $PWD
  63. Optionaly scan your bus if there are more then one usbg gadgets to find their path::
  64. $ python $kernel_dir/tools/usb/p9_fwd.py list
  65. Bus | Addr | Manufacturer | Product | ID | Path
  66. --- | ---- | ---------------- | ---------------- | --------- | ----
  67. 2 | 67 | unknown | unknown | 1d6b:0109 | 2-1.1.2
  68. 2 | 68 | unknown | unknown | 1d6b:0109 | 2-1.1.3
  69. Then start the python transport::
  70. $ python $kernel_dir/tools/usb/p9_fwd.py --path 2-1.1.2 connect -p 9999
  71. After that the gadget driver can be used as described above.
  72. One use-case is to use it as an alternative to NFS root booting during
  73. the development of embedded Linux devices.
  74. Options
  75. =======
  76. ============= ===============================================================
  77. trans=name select an alternative transport. Valid options are
  78. currently:
  79. ======== ============================================
  80. unix specifying a named pipe mount point
  81. tcp specifying a normal TCP/IP connection
  82. fd used passed file descriptors for connection
  83. (see rfdno and wfdno)
  84. virtio connect to the next virtio channel available
  85. (from QEMU with trans_virtio module)
  86. rdma connect to a specified RDMA channel
  87. usbg connect to a specified usb gadget channel
  88. ======== ============================================
  89. uname=name user name to attempt mount as on the remote server. The
  90. server may override or ignore this value. Certain user
  91. names may require authentication.
  92. aname=name aname specifies the file tree to access when the server is
  93. offering several exported file systems.
  94. cache=mode specifies a caching policy. By default, no caches are used.
  95. The mode can be specified as a bitmask or by using one of the
  96. preexisting common 'shortcuts'.
  97. The bitmask is described below: (unspecified bits are reserved)
  98. ========== ====================================================
  99. 0b00000000 all caches disabled, mmap disabled
  100. 0b00000001 file caches enabled
  101. 0b00000010 meta-data caches enabled
  102. 0b00000100 writeback behavior (as opposed to writethrough)
  103. 0b00001000 loose caches (no explicit consistency with server)
  104. 0b10000000 fscache enabled for persistent caching
  105. ========== ====================================================
  106. The current shortcuts and their associated bitmask are:
  107. ========= ====================================================
  108. none 0b00000000 (no caching)
  109. readahead 0b00000001 (only read-ahead file caching)
  110. mmap 0b00000101 (read-ahead + writeback file cache)
  111. loose 0b00001111 (non-coherent file and meta-data caches)
  112. fscache 0b10001111 (persistent loose cache)
  113. ========= ====================================================
  114. NOTE: only these shortcuts are tested modes of operation at the
  115. moment, so using other combinations of bit-patterns is not
  116. known to work. Work on better cache support is in progress.
  117. IMPORTANT: loose caches (and by extension at the moment fscache)
  118. do not necessarily validate cached values on the server. In other
  119. words changes on the server are not guaranteed to be reflected
  120. on the client system. Only use this mode of operation if you
  121. have an exclusive mount and the server will modify the filesystem
  122. underneath you.
  123. debug=n specifies debug level. The debug level is a bitmask.
  124. ===== ================================
  125. 0x01 display verbose error messages
  126. 0x02 developer debug (DEBUG_CURRENT)
  127. 0x04 display 9p trace
  128. 0x08 display VFS trace
  129. 0x10 display Marshalling debug
  130. 0x20 display RPC debug
  131. 0x40 display transport debug
  132. 0x80 display allocation debug
  133. 0x100 display protocol message debug
  134. 0x200 display Fid debug
  135. 0x400 display packet debug
  136. 0x800 display fscache tracing debug
  137. ===== ================================
  138. rfdno=n the file descriptor for reading with trans=fd
  139. wfdno=n the file descriptor for writing with trans=fd
  140. msize=n the number of bytes to use for 9p packet payload
  141. port=n port to connect to on the remote server
  142. noextend force legacy mode (no 9p2000.u or 9p2000.L semantics)
  143. version=name Select 9P protocol version. Valid options are:
  144. ======== ==============================
  145. 9p2000 Legacy mode (same as noextend)
  146. 9p2000.u Use 9P2000.u protocol
  147. 9p2000.L Use 9P2000.L protocol
  148. ======== ==============================
  149. dfltuid attempt to mount as a particular uid
  150. dfltgid attempt to mount with a particular gid
  151. afid security channel - used by Plan 9 authentication protocols
  152. nodevmap do not map special files - represent them as normal files.
  153. This can be used to share devices/named pipes/sockets between
  154. hosts. This functionality will be expanded in later versions.
  155. directio bypass page cache on all read/write operations
  156. ignoreqv ignore qid.version==0 as a marker to ignore cache
  157. noxattr do not offer xattr functions on this mount.
  158. access there are four access modes.
  159. user
  160. if a user tries to access a file on v9fs
  161. filesystem for the first time, v9fs sends an
  162. attach command (Tattach) for that user.
  163. This is the default mode.
  164. <uid>
  165. allows only user with uid=<uid> to access
  166. the files on the mounted filesystem
  167. any
  168. v9fs does single attach and performs all
  169. operations as one user
  170. clien
  171. ACL based access check on the 9p client
  172. side for access validation
  173. cachetag cache tag to use the specified persistent cache.
  174. cache tags for existing cache sessions can be listed at
  175. /sys/fs/9p/caches. (applies only to cache=fscache)
  176. ============= ===============================================================
  177. Behavior
  178. ========
  179. This section aims at describing 9p 'quirks' that can be different
  180. from a local filesystem behaviors.
  181. - Setting O_NONBLOCK on a file will make client reads return as early
  182. as the server returns some data instead of trying to fill the read
  183. buffer with the requested amount of bytes or end of file is reached.
  184. Resources
  185. =========
  186. Protocol specifications are maintained on github:
  187. http://ericvh.github.com/9p-rfc/
  188. 9p client and server implementations are listed on
  189. http://9p.cat-v.org/implementations
  190. A 9p2000.L server is being developed by LLNL and can be found
  191. at http://code.google.com/p/diod/
  192. There are user and developer mailing lists available through the v9fs project
  193. on sourceforge (http://sourceforge.net/projects/v9fs).
  194. News and other information is maintained on a Wiki.
  195. (http://sf.net/apps/mediawiki/v9fs/index.php).
  196. Bug reports are best issued via the mailing list.
  197. For more information on the Plan 9 Operating System check out
  198. http://plan9.bell-labs.com/plan9
  199. For information on Plan 9 from User Space (Plan 9 applications and libraries
  200. ported to Linux/BSD/OSX/etc) check out https://9fans.github.io/plan9port/