home *** CD-ROM | disk | FTP | other *** search
/ Black Box 4 / BlackBox.cdr / lan / sossexe.arj / DOC / SOS_DOC.TXT < prev    next >
Text File  |  1991-02-22  |  14KB  |  414 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.                   SOS - Stan's Own Server
  11.               A NFS file server for the IBM PC
  12.  
  13.  
  14.          See-Mong Tan, Harvard Holmes, Craig Eades
  15.  
  16.             Computer Science Research Department
  17.         Information and Computing Sciences Division
  18.                 Lawrence Berkeley Laboratory
  19.                      Berkeley, CA 94720
  20.  
  21.  
  22.                           _A_B_S_T_R_A_C_T
  23.  
  24.           SOS is a file server written to  run  on  the
  25.      IBM   PC   or  compatibles.  It  conforms  to  Sun
  26.      Microsystem's Network File System  (NFS)  protocol
  27.      version 2.  This paper discusses the SOS implemen-
  28.      tation and includes notes on portability, for pro-
  29.      grammers who wish to understand or modify it.
  30.  
  31.  
  32.  
  33. _1.  _I_n_t_r_o_d_u_c_t_i_o_n
  34.  
  35.      In general, a network of workstations provide more com-
  36. puting  power  than  a  standalone mainframe does.  Personal
  37. computers, however, face the problem  of  file  storage  and
  38. sharing,  since  some machines often do not have local disks
  39. attached (e.g. Sun 3/50s), while files needed  by  different
  40. users  must  be  transferred from one machine to another, by
  41. some program such as ftp.  This method of file sharing is at
  42. best still cumbersome.
  43.  
  44.      Sun Microsystem's introduction of NFS, the Network File
  45. System,  is designed to provide transparent access and shar-
  46. ing of files over a network.  In essence, files exist on the
  47. locally attached storage device of a machine called the _f_i_l_e
  48. _s_e_r_v_e_r, whose job is to accept requests  for  operations  on
  49. files  from  the  other  machines on the network, called the
  50. _c_l_i_e_n_t_s.  The clients _m_o_u_n_t filesystems on  the  server.   A
  51. filesystem is a directory on the server.  The _m_o_u_n_t _p_o_i_n_t on
  52. the client is the directory at which the client  chooses  to
  53. substitute  for  the  server  directory.   Any operations on
  54. files below the mount point are  trapped  by  the  operating
  55. system  and  mapped into appropriate requests to the server.
  56. Sun Microsystem's has also  recently  introduced  PC-NFS[1].
  57. PC-NFS  allows  IBM PC's or compatibles with ethernet inter-
  58. faces to become NFS clients on the network.
  59. _________________________
  60.   [1] PC-NFS is a trademark of Sun Microsystems, Inc.
  61.  
  62.  
  63.                       August 17, 1988
  64.  
  65.  
  66.  
  67.  
  68.  
  69.                            - 2 -
  70.  
  71.  
  72.      We have designed a file server conforming  to  the  NFS
  73. protocol  (version 2), that runs on the IBM PC.  This allows
  74. a dedicated PC to perform a task otherwise required of a Sun
  75. workstation  running NFS in kernel, or a VAX running a user-
  76. level NFS daemon.  The original project intended for a PC to
  77. serve  files from an optical disk to a heterogeneous network
  78. of Suns and PCs (with PC-NFS) as clients.
  79.  
  80. _2.  _M_a_n_a_g_i_n_g _C_o_n_c_u_r_r_e_n_c_y
  81.  
  82.      The  Sun  NFS  server  consists  of   three   different
  83. processes  running concurrently.  There is the mount daemon,
  84. port mapper and the server daemon proper.
  85.  
  86.      The mount daemon handles requests from a client  for  a
  87. filesystem  directory  to  be  mounted.   If  the request is
  88. valid, the mount daemon hands back to the client a _f_i_l_e _h_a_n_-
  89. _d_l_e.   The file handle contains context information, and the
  90. client must use it in further transactions with  the  server
  91. daemon.   The  handle  is  opaque  and varies from server to
  92. server.
  93.  
  94.      The server daemon performs  requested  file  operations
  95. such  as  reading  and  writing files, and reading of direc-
  96. tories.
  97.  
  98.      The port mapper always exists at  a  well  known  port,
  99. PMAPPORT,  which is equal to 111.  The server and mount dae-
  100. mons can theoretically be bound to any port,  and  the  port
  101. mapper  will  answer  queries from client machines regarding
  102. the port numbers of the other two daemons.  In version 2  of
  103. the NFS protocol however, the server is expected to be bound
  104. to port 2049.  Clients do not query the port mapper for  the
  105. NFS port.  This is a bug in the protocol which Sun Microsys-
  106. tem claims it will fix in the near future.
  107.  
  108.      MS-DOS  does  not  allow  concurrent  processes.    SOS
  109. includes  both  port mapper and mount programs together with
  110. the server.  Calls to these are by necessity sequential, not
  111. parallel.   Since  port mapper and mount requests are infre-
  112. quent compared to NFS  requests,  this  does  not  seriously
  113. hamper the server's performance.
  114.  
  115. _3.  _F_i_l_e _H_a_n_d_l_e_s _a_n_d _I_n_o_d_e_s
  116.  
  117.      Between a client and the server, a file  is  identified
  118. by  a  _f_i_l_e  _h_a_n_d_l_e.  NFS protocol specifies the length of a
  119. file handle to be 32 bytes.  In the Unix[2]  implementation,
  120. the  file  handle  contains  (among  other things) the inode
  121. number of the file.
  122. _________________________
  123.   [2] Unix is a trademark of Bell Laboratories.
  124.  
  125.  
  126.  
  127.  
  128.                       August 17, 1988
  129.  
  130.  
  131.  
  132.  
  133.  
  134.                            - 3 -
  135.  
  136.  
  137.      MS-DOS  does  not  explicitly   support   index   nodes
  138. (inodes).   Access  to  a  file  is  almost  completely path
  139. driven.  Since the file handle must be only 32  bytes  long,
  140. it is impractical to stuff the path name into the handle.  A
  141. 32 byte long path would only allow the shallowest  directory
  142. trees.   Thus,  SOS has an artificial inode interface to the
  143. files on  disk.   It  assigns  inode  numbers  to  files  as
  144. requests  arrive  for it to lookup or read.  An image of the
  145. filesystem tree is built in memory, and a file's  path  name
  146. is  reconstructed  from its inode number by referring to the
  147. filesystem tree.
  148.  
  149.      Since the inode numbers are artificial, they would  not
  150. be  preserved  if  the  server  crashes  or  is interrupted.
  151. Instead, the server writes to a file ("_i_n_o_d_e._d_m_p") the  path
  152. names of the files it had assigned inodes to.  SOS will read
  153. and reconstruct the filesystem tree  from  both  the  export
  154. file  and  the  inode  dump file when it is next started up.
  155. This means that SOS is not really stateless, because it must
  156. preserve  assigned  inode numbers from one invocation to the
  157. next.
  158.  
  159. _4.  _M_S-_D_O_S _C_o_n_s_t_r_a_i_n_t_s
  160.  
  161.      MS-DOS was not designed for a multi-user system.   Unix
  162. file  attributes  are inherently richer than can be put into
  163. an MS-DOS directory.
  164.  
  165.      All files in an  exported  SOS  filesystem  are  tagged
  166. owned  by  the superuser (user id of 0).  Further reflecting
  167. MS-DOS, files can exist in only  three  modes:  a  directory
  168. (global  read,  write  and execute), a normal file, which is
  169. globally readable, writeable and executable, and a read only
  170. file, which is a normal file sans write permission.
  171.  
  172.      This means that certain attributes  cannot  be  set  in
  173. exported files;  for example, chown(1) will not work at all,
  174. and chmod(1) will only affect write access.
  175.  
  176. _5.  _R_P_C/_X_D_R _I_n_t_e_r_f_a_c_e
  177.  
  178.      RPC and XDR stand for Remote Procedure Call and  Exter-
  179. nal  Data  Representation respectively.  RPC is a convention
  180. for calling remote procedures.  A server program is  identi-
  181. fied  by  its  program number and version number.  Each pro-
  182. cedure within  a  program  is  represented  by  a  procedure
  183. number.   For example, the read procedure in a NFS server is
  184. identified by this triple:  100003 (program number), 2 (ver-
  185. sion  number),  6  (procedure  number).  A client wishing to
  186. read a particular file would send a request to the server in
  187. the form of the previous identifying triple, followed by the
  188. file's file handle.  In order to decipher what is sent  over
  189. the  wire,  both  servers  and clients use the XDR routines.
  190. XDR encodes and decodes data sent  over  the  network  in  a
  191.  
  192.  
  193.  
  194.                       August 17, 1988
  195.  
  196.  
  197.  
  198.  
  199.  
  200.                            - 4 -
  201.  
  202.  
  203. format not dependent on each machine's architecture.
  204.  
  205.      Sun NFS runs on an RPC/XDR interface.   We  ported  the
  206. public  domain  Sun  server side RPC and XDR code to the PC.
  207. Only a few minor changes were made.  One  was  allowing  the
  208. procedure  svcudp_create() to take two arguments, the second
  209. of which specifies whether to use a large  (8800  byte)  UDP
  210. send  and  receive  buffer,  or  to  use  a small (400 byte)
  211. buffer.  The port mapper and  mount  daemon  use  the  small
  212. sized  version,  and  the server daemon uses the large sized
  213. buffer.  Also, the ported RPC  procedures  do  not  register
  214. services with the port mapper.  The SOS port mapper knows of
  215. only two service ports, the mount daemon port and the server
  216. daemon port, which are compiled into SOS.
  217.  
  218.      Only datagrams are used in SOS;  the TCP interface  was
  219. not  moved.  This mainly affects the port mapper.  It cannot
  220. receive TCP requests.
  221.  
  222. _6.  _I_P_C _I_n_t_e_r_f_a_c_e
  223.  
  224.      The project used a PC  attached  to  the  net  with  an
  225. Excelan EXOS card.
  226.  
  227.      The Excelan EXOS package provided  a  socket  interface
  228. quite  similar to 4.2 BSD UNIX.  A seperate module was writ-
  229. ten  on  top  of  the  Excelan  library  ("_s_o_c_k._c").    This
  230. abstracts the socket interface which the rest of the program
  231. sees from Excelan  specific  details.   Portability  in  the
  232. future  to  a different ethernet card will simply consist of
  233. rewriting this module in concert with the new  library  pro-
  234. vided.
  235.  
  236. _7.  _S_o_m_e _D_i_f_f_i_c_u_l_t_i_e_s _E_n_c_o_u_n_t_e_r_e_d
  237.  
  238.      Before we moved development to a  PC  with  an  Excelan
  239. ethernet  card,  we  tried  to  write  the server on another
  240. machine running PC-NFS.  PC-NFS provides  a  very  congenial
  241. environment  for writing a server.  The toolkit provides XDR
  242. routines and client side RPC routines, as well as a good 4.2
  243. BSD  Unix  socket  and networking interface.  Unfortunately,
  244. PC-NFS uses the local port number 2049 for its own  transac-
  245. tions.  In NFS protocol version 2, port 2049 is the de facto
  246. NFS port, and clients do not query the port mapper  for  the
  247. port  number  of  the  server.   This  means that any PC-NFS
  248. client cannot also be a server.  We were forced  to  abandon
  249. this  approach and use a PC with an Excelan card and Excelan
  250. software instead.
  251.  
  252. _8.  _S_e_r_v_e_r _P_e_r_f_o_r_m_a_n_c_e
  253.  
  254.      Some informal timings of server performance were  done.
  255. We  compared  the  speeds  taken  to  access a large file by
  256. several different clients, from both a Sun 3/280 server  and
  257.  
  258.  
  259.  
  260.                       August 17, 1988
  261.  
  262.  
  263.  
  264.  
  265.  
  266.                            - 5 -
  267.  
  268.  
  269. a  PC  running  SOS.  The reference SOS configuration was an
  270. IBM PC with a hard disk drive[3].
  271.  
  272.      The Sun runs at 25 MHz with twenty times the  bandwidth
  273. of  the  4.77  MHz  IBM PC.  On the average, SOS on a PC was
  274. about nine times slower than the Sun, with a PC as a client.
  275. With  a  Sun client, SOS was some seventy times slower.  The
  276. table below shows transfer rates in kilobytes per second.
  277.  
  278.  
  279.     ____________________________________________________
  280.            Transfer rates in kilobytes per second
  281.     ____________________________________________________
  282.                                  Servers
  283.       Clients     PC (SOS)   VAX (11/785)   Sun (3/280)
  284.     ________________________________________________________________________________________________________
  285.      IBM PC         4.2          14.4           36.0
  286.      Compaq 386     4.4          17.7          125.9
  287.      Sun 3/60       2.9         100.7          220.0
  288.     ____________________________________________________
  289.    ||||||||
  290.  
  291.  
  292.  
  293.  
  294.  
  295.                ||||||
  296.  
  297.  
  298.  
  299.  
  300.                                                        ||||||||
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  309. Note that the performance of the  Sun  client  with  the  PC
  310. server  is  not  as good compared to the PC and 386 clients.
  311. This irregularity is explained by  the  fact  that  the  Sun
  312. client tends to time out before the PC server's reply, hence
  313. causing a double read request to be sent out.
  314.  
  315.      Running the server in verbose mode  (where  the  server
  316. advises  of  all  incoming  requests)  slowed performance by
  317. about two-thirds.  Running the server  with  files  accessed
  318. from  a  virtual  disk (RAM disk) created in memory gained a
  319. 20% increase in performance.
  320.  
  321. _9.  _I_m_p_r_o_v_e_m_e_n_t_s
  322.  
  323.      The port  mapper  and  mount  daemons  are  incomplete.
  324. Clients  currently cannot dump listings of ports or exported
  325. filesytems from the server.
  326.  
  327.      The inode interface  is  inelegant.   A  better  scheme
  328. would  be  to  use  the starting cluster numbers of files on
  329. disk to serve as inode numbers.  We suspect that this  would
  330. involve quite some work.
  331.  
  332. _1_0.  _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s
  333.  
  334.      Fred Gey's generosity in loaning us his  PC  for  SOS's
  335. development  over one summer is greatly appreciated.  Thanks
  336. to David Robertson for his bug free host to network and net-
  337. work to host data conversion procedures.  We are also grate-
  338. ful to Bill Johnston for his  help  in  troubleshooting  PC-
  339. NFS's perculiarities.
  340. _________________________
  341.   [3] We used a Microcode 20 Megabyte hard drive.
  343.  
  344.  
  345.                       August 17, 1988
  346.  
  347.  
  348.  
  349.  
  350.  
  351.                            - 6 -
  352.  
  353.  
  354. _1_1.  _C_o_m_m_e_n_t_s
  355.  
  356.      Bugs and comments should be sent to:
  357.  
  358.                 stan@lbl-csam.arpa, stan@lbl-csam.lbl.doe.gov, lbl-csam.arpa!stan
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.                       August 17, 1988
  412.  
  413.  
  414.