[4464594] | 1 | RTEMS-NFS |
---|
| 2 | ========= |
---|
| 3 | |
---|
| 4 | A NFS-V2 client implementation for the RTEMS real-time |
---|
| 5 | executive. |
---|
| 6 | |
---|
| 7 | Author: Till Straumann <strauman@slac.stanford.edu>, 2002 |
---|
| 8 | |
---|
| 9 | Copyright 2002, Stanford University and |
---|
| 10 | Till Straumann <strauman@slac.stanford.edu> |
---|
| 11 | |
---|
| 12 | Stanford Notice |
---|
| 13 | *************** |
---|
| 14 | |
---|
| 15 | Acknowledgement of sponsorship |
---|
| 16 | * * * * * * * * * * * * * * * * |
---|
| 17 | This software was produced by the Stanford Linear Accelerator Center, |
---|
| 18 | Stanford University, under Contract DE-AC03-76SFO0515 with the Department |
---|
| 19 | of Energy. |
---|
| 20 | |
---|
| 21 | |
---|
| 22 | Contents |
---|
| 23 | -------- |
---|
| 24 | I Overview |
---|
| 25 | 1) Performance |
---|
| 26 | 2) Reference Platform / Test Environment |
---|
| 27 | |
---|
| 28 | II Usage |
---|
| 29 | 1) Initialization |
---|
| 30 | 2) Mounting Remote Server Filesystems |
---|
| 31 | 3) Unmounting |
---|
| 32 | 4) Unloading |
---|
| 33 | 5) Dumping Information / Statistics |
---|
| 34 | |
---|
| 35 | III Implementation Details |
---|
| 36 | 1) RPCIOD |
---|
| 37 | 2) NFS |
---|
| 38 | 3) RTEMS Resources Used By NFS/RPCIOD |
---|
| 39 | 4) Caveats & Bugs |
---|
| 40 | |
---|
| 41 | IV Licensing & Disclaimers |
---|
| 42 | |
---|
| 43 | I Overview |
---|
| 44 | ----------- |
---|
| 45 | |
---|
| 46 | This package implements a simple non-caching NFS |
---|
| 47 | client for RTEMS. Most of the system calls are |
---|
| 48 | supported with the exception of 'mount', i.e. it |
---|
| 49 | is not possible to mount another FS on top of NFS |
---|
| 50 | (mostly because of the difficulty that arises when |
---|
| 51 | mount points are deleted on the server). It |
---|
| 52 | shouldn't be hard to do, though. |
---|
| 53 | |
---|
| 54 | Note: this client supports NFS vers. 2 / MOUNT vers. 1; |
---|
| 55 | NFS Version 3 or higher are NOT supported. |
---|
| 56 | |
---|
| 57 | The package consists of two modules: RPCIOD and NFS |
---|
| 58 | itself. |
---|
| 59 | |
---|
| 60 | - RPCIOD is a UDP/RPC multiplexor daemon. It takes |
---|
| 61 | RPC requests from multiple local client threads, |
---|
| 62 | funnels them through a single socket to multiple |
---|
| 63 | servers and dispatches the replies back to the |
---|
| 64 | (blocked) requestor threads. |
---|
| 65 | RPCIOD does packet retransmission and handles |
---|
| 66 | timeouts etc. |
---|
| 67 | Note however, that it does NOT do any XDR |
---|
| 68 | marshalling - it is up to the requestor threads |
---|
| 69 | to do the XDR encoding/decoding. RPCIOD _is_ RPC |
---|
| 70 | specific, though, because its message dispatching |
---|
| 71 | is based on the RPC transaction ID. |
---|
| 72 | |
---|
| 73 | - The NFS package maps RTEMS filesystem calls |
---|
| 74 | to proper RPCs, it does the XDR work and |
---|
| 75 | hands marshalled RPC requests to RPCIOD. |
---|
| 76 | All of the calls are synchronous, i.e. they |
---|
| 77 | block until they get a reply. |
---|
| 78 | |
---|
| 79 | 1) Performance |
---|
| 80 | - - - - - - - - |
---|
| 81 | Performance sucks (due to the lack of |
---|
| 82 | readahead/delayed write and caching). On a fast |
---|
| 83 | (100Mb/s) ethernet, it takes about 20s to copy a |
---|
| 84 | 10MB file from NFS to NFS. I found, however, that |
---|
| 85 | vxWorks' NFS client doesn't seem to be any |
---|
| 86 | faster... |
---|
| 87 | |
---|
| 88 | Since there is no buffer cache with read-ahead |
---|
| 89 | implemented, all NFS reads are synchronous RPC |
---|
| 90 | calls. Every read operation involves sending a |
---|
| 91 | request and waiting for the reply. As long as the |
---|
| 92 | overhead (sending request + processing it on the |
---|
| 93 | server) is significant compared to the time it |
---|
| 94 | takes to transferring the actual data, increasing |
---|
| 95 | the amount of data per request results in better |
---|
| 96 | throughput. The UDP packet size limit imposes a |
---|
| 97 | limit of 8k per RPC call, hence reading from NFS |
---|
| 98 | in chunks of 8k is better than chunks of 1k [but |
---|
| 99 | chunks >8k are not possible, i.e., simply not |
---|
| 100 | honoured: read(a_nfs_fd, buf, 20000) returns |
---|
| 101 | 8192]. This is similar to the old linux days |
---|
| 102 | (mount with rsize=8k). You can let stdio take |
---|
| 103 | care of the buffering or use 8k buffers with |
---|
| 104 | explicit read(2) operations. Note that stdio |
---|
| 105 | honours the file-system's st_blksize field |
---|
| 106 | if newlib is compiled with HAVE_BLKSIZE defined. |
---|
| 107 | In this case, stdio uses 8k buffers for files |
---|
| 108 | on NFS transparently. The blocksize NFS |
---|
| 109 | reports can be tuned with a global variable |
---|
| 110 | setting (see nfs.c for details). |
---|
| 111 | |
---|
| 112 | Further increase of throughput can be achieved |
---|
| 113 | with read-ahead (issuing RPC calls in parallel |
---|
| 114 | [send out request for block n+1 while you are |
---|
| 115 | waiting for data of block n to arrive]). Since |
---|
| 116 | this is not handled by the file system itself, you |
---|
| 117 | would have to code this yourself e.g., using |
---|
| 118 | parallel threads to read from a single file from |
---|
| 119 | interleaved offsets. |
---|
| 120 | |
---|
| 121 | Another obvious improvement can be achieved if |
---|
| 122 | processing the data takes a significant amount of |
---|
| 123 | time. Then, having a pipeline of threads for |
---|
| 124 | reading data and processing them makes sense |
---|
| 125 | [thread b processes chunk n while thread a blocks |
---|
| 126 | in read(chunk n+1)]. |
---|
| 127 | |
---|
| 128 | Some performance figures: |
---|
| 129 | Software: src/nfsTest.c:nfsReadTest() [data not |
---|
| 130 | processed in any way]. |
---|
| 131 | Hardware: MVME6100 |
---|
| 132 | Network: 100baseT-FD |
---|
| 133 | Server: Linux-2.6/RHEL4-smp [dell precision 420] |
---|
| 134 | File: 10MB |
---|
| 135 | |
---|
| 136 | Results: |
---|
| 137 | Single threaded ('normal') NFS read, 1k buffers: 3.46s (2.89MB/s) |
---|
| 138 | Single threaded ('normal') NFS read, 8k buffers: 1.31s (7.63MB/s) |
---|
| 139 | Multi threaded; 2 readers, 8k buffers/xfers: 1.12s (8.9 MB/s) |
---|
| 140 | Multi threaded; 3 readers, 8k buffers/xfers: 1.04s (9.6 MB/s) |
---|
| 141 | |
---|
| 142 | 2) Reference Platform |
---|
| 143 | - - - - - - - - - - - |
---|
| 144 | RTEMS-NFS was developed and tested on |
---|
| 145 | |
---|
| 146 | o RTEMS-ss20020301 (local patches applied) |
---|
| 147 | o PowerPC G3, G4 on Synergy SVGM series board |
---|
| 148 | (custom 'SVGM' BSP, to be released soon) |
---|
| 149 | o PowerPC 604 on MVME23xx |
---|
| 150 | (powerpc/shared/motorola-powerpc BSP) |
---|
| 151 | o Test Environment: |
---|
| 152 | - RTEMS executable running CEXP |
---|
| 153 | - rpciod/nfs dynamically loaded from TFTPfs |
---|
| 154 | - EPICS application dynamically loaded from NFS; |
---|
| 155 | the executing IOC accesses all of its files |
---|
| 156 | on NFS. |
---|
| 157 | |
---|
| 158 | II Usage |
---|
| 159 | --------- |
---|
| 160 | |
---|
| 161 | After linking into the system and proper initialization |
---|
| 162 | (rtems-NFS supports 'magic' module initialization when |
---|
| 163 | loaded into a running system with the CEXP loader), |
---|
| 164 | you are ready for mounting NFSes from a server |
---|
| 165 | (I avoid the term NFS filesystem because NFS already |
---|
| 166 | stands for 'Network File System'). |
---|
| 167 | |
---|
| 168 | You should also read the |
---|
| 169 | |
---|
| 170 | - "RTEMS Resources Used By NFS/RPCIOD" |
---|
| 171 | - "CAVEATS & BUGS" |
---|
| 172 | |
---|
| 173 | below. |
---|
| 174 | |
---|
| 175 | 1) Initialization |
---|
| 176 | - - - - - - - - - |
---|
| 177 | NFS consists of two modules who must be initialized: |
---|
| 178 | |
---|
| 179 | a) the RPCIO daemon package; by calling |
---|
| 180 | |
---|
| 181 | rpcUdpInit(); |
---|
| 182 | |
---|
| 183 | note that this step must be performed prior to |
---|
| 184 | initializing NFS: |
---|
| 185 | |
---|
| 186 | b) NFS is initialized by calling |
---|
| 187 | |
---|
| 188 | nfsInit( smallPoolDepth, bigPoolDepth ); |
---|
| 189 | |
---|
| 190 | if you supply 0 (zero) values for the pool |
---|
| 191 | depths, the compile-time default configuration |
---|
| 192 | is used which should work fine. |
---|
| 193 | |
---|
| 194 | NOTE: when using CEXP to load these modules into a |
---|
| 195 | running system, initialization will be performed |
---|
| 196 | automagically. |
---|
| 197 | |
---|
| 198 | 2) Mounting Remote Server Filesystems |
---|
| 199 | - - - - - - - - - - - - - - - - - - - |
---|
| 200 | |
---|
| 201 | There are two interfaces for mounting an NFS: |
---|
| 202 | |
---|
| 203 | - The (non-POSIX) RTEMS 'mount()' call: |
---|
| 204 | |
---|
| 205 | mount( &mount_table_entry_pointer, |
---|
| 206 | &filesystem_operations_table_pointer, |
---|
| 207 | options, |
---|
| 208 | device, |
---|
| 209 | mount_point ) |
---|
| 210 | |
---|
| 211 | Note that you must specify a 'mount_table_entry_pointer' |
---|
| 212 | (use a dummy) - RTEMS' mount() doesn't grok a NULL for |
---|
| 213 | the first argument. |
---|
| 214 | |
---|
| 215 | o for the 'filesystem_operations_table_pointer', supply |
---|
| 216 | |
---|
| 217 | &nfs_fs_ops |
---|
| 218 | |
---|
| 219 | o options are constants (see RTEMS headers) for specifying |
---|
| 220 | read-only / read-write mounts. |
---|
| 221 | |
---|
| 222 | o the 'device' string specifies the remote filesystem |
---|
| 223 | who is to be mounted. NFS expects a string conforming |
---|
| 224 | to the following format (EBNF syntax): |
---|
| 225 | |
---|
| 226 | [ <uid> '.' <gid> '@' ] <hostip> ':' <path> |
---|
| 227 | |
---|
| 228 | The first optional part of the string allows you |
---|
| 229 | to specify the credentials to be used for all |
---|
| 230 | subsequent transactions with this server. If the |
---|
| 231 | string is omitted, the EUID/EGID of the executing |
---|
| 232 | thread (i.e. the thread performing the 'mount' - |
---|
| 233 | NFS will still 'remember' these values and use them |
---|
| 234 | for all future communication with this server). |
---|
| 235 | |
---|
| 236 | The <hostip> part denotes the server IP address |
---|
| 237 | in standard 'dot' notation. It is followed by |
---|
| 238 | a colon and the (absolute) path on the server. |
---|
| 239 | Note that no extra characters or whitespace must |
---|
| 240 | be present in the string. Example 'device' strings |
---|
| 241 | are: |
---|
| 242 | |
---|
| 243 | "300.99@192.168.44.3:/remote/rtems/root" |
---|
| 244 | |
---|
| 245 | "192.168.44.3:/remote/rtems/root" |
---|
| 246 | |
---|
| 247 | o the 'mount_point' string identifies the local |
---|
| 248 | directory (most probably on IMFS) where the NFS |
---|
| 249 | is to be mounted. Note that the mount point must |
---|
| 250 | already exist with proper permissions. |
---|
| 251 | |
---|
| 252 | - Alternate 'mount' interface. NFS offers a more |
---|
| 253 | convenient wrapper taking three string arguments: |
---|
| 254 | |
---|
| 255 | nfsMount(uidgid_at_host, server_path, mount_point) |
---|
| 256 | |
---|
| 257 | This interface does DNS lookup (see reentrancy note |
---|
| 258 | below) and creates the mount point if necessary. |
---|
| 259 | |
---|
| 260 | o the first argument specifies the server and |
---|
| 261 | optionally the uid/gid to be used for authentication. |
---|
| 262 | The semantics are exactly as described above: |
---|
| 263 | |
---|
| 264 | [ <uid> '.' <gid> '@' ] <host> |
---|
| 265 | |
---|
| 266 | The <host> part may be either a host _name_ or |
---|
| 267 | an IP address in 'dot' notation. In the former |
---|
| 268 | case, nfsMount() uses 'gethostbyname()' to do |
---|
| 269 | a DNS lookup. |
---|
| 270 | |
---|
| 271 | IMPORTANT NOTE: gethostbyname() is NOT reentrant/ |
---|
| 272 | thread-safe and 'nfsMount()' (if not provided with an |
---|
| 273 | IP/dot address string) is hence subject to race conditions. |
---|
| 274 | |
---|
| 275 | o the 'server_path' and 'mount_point' arguments |
---|
| 276 | are described above. |
---|
| 277 | NOTE: If the mount point does not exist yet, |
---|
| 278 | nfsMount() tries to create it. |
---|
| 279 | |
---|
| 280 | o if nfsMount() is called with a NULL 'uidgid_at_host' |
---|
| 281 | argument, it lists all currently mounted NFS |
---|
| 282 | |
---|
| 283 | 3) Unmounting |
---|
| 284 | - - - - - - - |
---|
| 285 | An NFS can be unmounted using RTEMS 'unmount()' |
---|
| 286 | call (yep, it is unmount() - not umount()): |
---|
| 287 | |
---|
| 288 | unmount(mount_point) |
---|
| 289 | |
---|
| 290 | Note that you _must_ supply the mount point (string |
---|
| 291 | argument). It is _not_ possible to specify the |
---|
| 292 | 'mountee' when unmounting. NFS implements no |
---|
| 293 | convenience wrapper for this (yet), essentially because |
---|
| 294 | (although this sounds unbelievable) it is non-trivial |
---|
| 295 | to lookup the path leading to an RTEMS filesystem |
---|
| 296 | directory node. |
---|
| 297 | |
---|
| 298 | 4) Unloading |
---|
| 299 | - - - - - - - |
---|
| 300 | After unmounting all NFS from the system, the NFS |
---|
| 301 | and RPCIOD modules may be stopped and unloaded. |
---|
| 302 | Just call 'nfsCleanup()' and 'rpcUdpCleanup()' |
---|
| 303 | in this order. You should evaluate the return value |
---|
| 304 | of these routines which is non-zero if either |
---|
| 305 | of them refuses to yield (e.g. because there are |
---|
| 306 | still mounted filesystems). |
---|
| 307 | Again, when unloading is done by CEXP this is |
---|
| 308 | transparently handled. |
---|
| 309 | |
---|
| 310 | 5) Dumping Information / Statistics |
---|
| 311 | - - - - - - - - - - - - - - - - - - |
---|
| 312 | |
---|
| 313 | Rudimentary RPCIOD statistics are printed |
---|
| 314 | to a file (stdout when NULL) by |
---|
| 315 | |
---|
| 316 | int rpcUdpStats(FILE *f) |
---|
| 317 | |
---|
| 318 | A list of all currently mounted NFS can be |
---|
| 319 | printed to a file (stdout if NULL) using |
---|
| 320 | |
---|
| 321 | int nfsMountsShow(FILE *f) |
---|
| 322 | |
---|
| 323 | For convenience, this routine is also called |
---|
| 324 | by nfsMount() when supplying NULL arguments. |
---|
| 325 | |
---|
| 326 | III Implementation Details |
---|
| 327 | -------------------------- |
---|
| 328 | |
---|
| 329 | 1) RPCIOD |
---|
| 330 | - - - - - |
---|
| 331 | |
---|
| 332 | RPCIOD was created to |
---|
| 333 | |
---|
| 334 | a) avoid non-reentrant librpc calls. |
---|
| 335 | b) support 'asynchronous' operation over a single |
---|
| 336 | socket. |
---|
| 337 | |
---|
| 338 | RPCIOD is a daemon thread handling 'transaction objects' |
---|
| 339 | (XACTs) through an UDP socket. XACTs are marshalled RPC |
---|
| 340 | calls/replies associated with RPC servers and requestor |
---|
| 341 | threads. |
---|
| 342 | |
---|
| 343 | requestor thread: network: |
---|
| 344 | |
---|
| 345 | XACT packet |
---|
| 346 | | | |
---|
| 347 | V V |
---|
| 348 | | message queue | ( socket ) |
---|
| 349 | | | ^ |
---|
| 350 | ----------> <----- | | |
---|
| 351 | RPCIOD | |
---|
| 352 | / -------------- |
---|
| 353 | timeout/ (re) transmission |
---|
| 354 | |
---|
| 355 | |
---|
| 356 | A requestor thread drops a transaction into |
---|
| 357 | the message queue and goes to sleep. The XACT is |
---|
| 358 | picked up by rpciod who is listening for events from |
---|
| 359 | three sources: |
---|
| 360 | |
---|
| 361 | o the request queue |
---|
| 362 | o packet arrival at the socket |
---|
| 363 | o timeouts |
---|
| 364 | |
---|
| 365 | RPCIOD sends the XACT to its destination server and |
---|
| 366 | enqueues the pending XACT into an ordered list of |
---|
| 367 | outstanding transactions. |
---|
| 368 | |
---|
| 369 | When a packet arrives, RPCIOD (based on the RPC transaction |
---|
| 370 | ID) looks up the matching XACT and wakes up the requestor |
---|
| 371 | who can then XDR-decode the RPC results found in the XACT |
---|
| 372 | object's buffer. |
---|
| 373 | |
---|
| 374 | When a timeout expires, RPCIOD examines the outstanding |
---|
| 375 | XACT that is responsible for the timeout. If its lifetime |
---|
| 376 | has not expired yet, RPCIOD resends the request. Otherwise, |
---|
| 377 | the XACT's error status is set and the requestor is woken up. |
---|
| 378 | |
---|
| 379 | RPCIOD dynamically adjusts the retransmission intervals |
---|
| 380 | based on the average round-trip time measured (on a per-server |
---|
| 381 | basis). |
---|
| 382 | |
---|
| 383 | Having the requestors event driven (rather than blocking |
---|
| 384 | e.g. on a semaphore) is geared to having many different |
---|
| 385 | requestors (one synchronization object per requestor would |
---|
| 386 | be needed otherwise). |
---|
| 387 | |
---|
| 388 | Requestors who want to do asynchronous IO need a different |
---|
| 389 | interface which will be added in the future. |
---|
| 390 | |
---|
| 391 | 1.a) Reentrancy |
---|
| 392 | - - - - - - - - |
---|
| 393 | RPCIOD does no non-reentrant librpc calls. |
---|
| 394 | |
---|
| 395 | 1.b) Efficiency |
---|
| 396 | - - - - - - - - |
---|
| 397 | We shouldn't bother about efficiency until pipelining (read-ahead/ |
---|
| 398 | delayed write) and caching are implemented. The round-trip delay |
---|
| 399 | associated with every single RPC transaction clearly is a big |
---|
| 400 | performance killer. |
---|
| 401 | |
---|
| 402 | Nevertheless, I could not withstand the temptation to eliminate |
---|
| 403 | the extra copy step involved with socket IO: |
---|
| 404 | |
---|
| 405 | A user data object has to be XDR encoded into a buffer. The |
---|
| 406 | buffer given to the socket where it is copied into MBUFs. |
---|
| 407 | (The network chip driver might even do more copying). |
---|
| 408 | |
---|
| 409 | Likewise, on reception 'recvfrom' copies MBUFS into a user |
---|
| 410 | buffer which is XDR decoded into the final user data object. |
---|
| 411 | |
---|
| 412 | Eliminating the copying into (possibly multiple) MBUFS by |
---|
| 413 | 'sendto()' is actually a piece of cake. RPCIOD uses the |
---|
| 414 | 'sosend()' routine [properly wrapped] supplying a single |
---|
| 415 | MBUF header who directly points to the marshalled buffer |
---|
| 416 | :-) |
---|
| 417 | |
---|
| 418 | Getting rid of the extra copy on reception was (only a little) |
---|
| 419 | harder: I derived a 'XDR-mbuf' stream from SUN's xdr_mem which |
---|
| 420 | allows for XDR-decoding out of a MBUF chain who is obtained by |
---|
| 421 | soreceive(). |
---|
| 422 | |
---|
| 423 | 2) NFS |
---|
| 424 | - - - - |
---|
| 425 | The actual NFS implementation is straightforward and essentially |
---|
| 426 | 'passive' (no threads created). Any RTEMS task executing a |
---|
| 427 | filesystem call dispatched to NFS (such as 'opendir()', 'lseek()' |
---|
| 428 | or 'unlink()') ends up XDR encoding arguments, dropping a |
---|
| 429 | XACT into RPCIOD's message queue and going to sleep. |
---|
| 430 | When woken up by RPCIOD, the XACT is decoded (using the XDR-mbuf |
---|
| 431 | stream mentioned above) and the properly cooked-up results are |
---|
| 432 | returned. |
---|
| 433 | |
---|
| 434 | 3) RTEMS Resources Used By NFS/RPCIOD |
---|
| 435 | - - - - - - - - - - - - - - - - - - - |
---|
| 436 | |
---|
| 437 | The RPCIOD/NFS package uses the following resources. Some |
---|
| 438 | parameters are compile-time configurable - consult the |
---|
| 439 | source files for details. |
---|
| 440 | |
---|
| 441 | RPCIOD: |
---|
| 442 | o 1 task |
---|
| 443 | o 1 message queue |
---|
| 444 | o 1 socket/filedescriptor |
---|
| 445 | o 2 semaphores (a third one is temporarily created during |
---|
| 446 | rpcUdpCleanup()). |
---|
| 447 | o 1 RTEMS EVENT (by default RTEMS_EVENT_30). |
---|
| 448 | IMPORTANT: this event is used by _every_ thread executing |
---|
| 449 | NFS system calls and hence is RESERVED. |
---|
| 450 | o 3 events only used by RPCIOD itself, i.e. these must not |
---|
| 451 | be sent to RPCIOD by no other thread (except for the intended |
---|
| 452 | use, of course). The events involved are 1,2,3. |
---|
| 453 | o preemption disabled sections: NONE |
---|
| 454 | o sections with interrupts disabled: NONE |
---|
| 455 | o NO 'timers' are used (timer code would run in IRQ context) |
---|
| 456 | o memory usage: n.a |
---|
| 457 | |
---|
| 458 | NFS: |
---|
| 459 | o 2 message queues |
---|
| 460 | o 2 semaphores |
---|
| 461 | o 1 semaphore per mounted NFS |
---|
| 462 | o 1 slot in driver entry table (for major number) |
---|
| 463 | o preemption disabled sections: NONE |
---|
| 464 | o sections with interrupts disabled: NONE |
---|
| 465 | o 1 task + 1 semaphore temporarily created when |
---|
| 466 | listing mounted filesystems (rtems_filesystem_resolve_location()) |
---|
| 467 | |
---|
| 468 | 4) CAVEATS & BUGS |
---|
| 469 | - - - - - - - - - |
---|
| 470 | Unfortunately, some bugs crawl around in the filesystem generics. |
---|
| 471 | (Some of them might already be fixed in versions later than |
---|
| 472 | rtems-ss-20020301). |
---|
| 473 | I recommend to use the patch distributed with RTEMS-NFS. |
---|
| 474 | |
---|
| 475 | o RTEMS uses/used (Joel said it has been fixed already) a 'short' |
---|
| 476 | ino_t which is not enough for NFS. |
---|
| 477 | The driver detects this problem and enables a workaround. In rare |
---|
| 478 | situations (mainly involving 'getcwd()' improper inode comparison |
---|
| 479 | may result (due to the restricted size, stat() returns st_ino modulo |
---|
| 480 | 2^16). In most cases, however, st_dev is compared along with st_ino |
---|
| 481 | which will give correct results (different files may yield identical |
---|
| 482 | st_ino but they will have different st_dev). However, there is |
---|
| 483 | code (in getcwd(), for example) who assumes that files residing |
---|
| 484 | in one directory must be hosted by the same device and hence omits |
---|
| 485 | the st_dev comparison. In such a case, the workaround will fail. |
---|
| 486 | |
---|
| 487 | NOTE: changing the size (sys/types.h) of ino_t from 'short' to 'long' |
---|
| 488 | is strongly recommended. It is NOT included in the patch, however |
---|
| 489 | as this is a major change requiring ALL of your sources to |
---|
| 490 | be recompiled. |
---|
| 491 | |
---|
| 492 | THE ino_t SIZE IS FIXED IN GCC-3.2/NEWLIB-1.10.0-2 DISTRIBUTED BY |
---|
| 493 | OAR. |
---|
| 494 | |
---|
| 495 | o You may work around most filesystem bugs by observing the following |
---|
| 496 | rules: |
---|
| 497 | |
---|
| 498 | * never use chroot() (fixed by the patch) |
---|
| 499 | * never use getpwent(), getgrent() & friends - they are NOT THREAD |
---|
| 500 | safe (fixed by the patch) |
---|
| 501 | * NEVER use rtems_libio_share_private_env() - not even with the |
---|
| 502 | patch applied. Just DONT - it is broken by design. |
---|
| 503 | * All threads who have their own userenv (who have called |
---|
| 504 | rtems_libio_set_private_env()) SHOULD 'chdir("/")' before |
---|
| 505 | terminating. Otherwise, (i.e. if their cwd is on NFS), it will |
---|
| 506 | be impossible to unmount the NFS involved. |
---|
| 507 | |
---|
| 508 | o The patch slightly changes the semantics of 'getpwent()' and |
---|
| 509 | 'getgrent()' & friends (to what is IMHO correct anyways - the patch is |
---|
| 510 | also needed to fix another problem, however): with the patch applied, |
---|
| 511 | the passwd and group files are always accessed from the 'current' user |
---|
| 512 | environment, i.e. a thread who has changed its 'root' or 'uid' might |
---|
| 513 | not be able to access these files anymore. |
---|
| 514 | |
---|
| 515 | o NOTE: RTEMS 'mount()' / 'unmount()' are NOT THREAD SAFE. |
---|
| 516 | |
---|
| 517 | o The NFS protocol has no 'append' or 'seek_end' primitive. The client |
---|
| 518 | must query the current file size (this client uses cached info) and |
---|
| 519 | change the local file pointer accordingly (in 'O_APPEND' mode). |
---|
| 520 | Obviously, this involves a race condition and hence multiple clients |
---|
| 521 | writing the same file may lead to corruption. |
---|
| 522 | |
---|
| 523 | IV Licensing & Disclaimers |
---|
| 524 | -------------------------- |
---|
| 525 | |
---|
| 526 | NFS is distributed under the SLAC License - consult the |
---|
| 527 | separate 'LICENSE' file. |
---|
| 528 | |
---|
| 529 | Government disclaimer of liability |
---|
| 530 | - - - - - - - - - - - - - - - - - |
---|
| 531 | Neither the United States nor the United States Department of Energy, |
---|
| 532 | nor any of their employees, makes any warranty, express or implied, |
---|
| 533 | or assumes any legal liability or responsibility for the accuracy, |
---|
| 534 | completeness, or usefulness of any data, apparatus, product, or process |
---|
| 535 | disclosed, or represents that its use would not infringe privately |
---|
| 536 | owned rights. |
---|
| 537 | |
---|
| 538 | Stanford disclaimer of liability |
---|
| 539 | - - - - - - - - - - - - - - - - - |
---|
| 540 | Stanford University makes no representations or warranties, express or |
---|
| 541 | implied, nor assumes any liability for the use of this software. |
---|
| 542 | |
---|
| 543 | Maintenance of notice |
---|
| 544 | - - - - - - - - - - - |
---|
| 545 | In the interest of clarity regarding the origin and status of this |
---|
| 546 | software, Stanford University requests that any recipient of it maintain |
---|
| 547 | this notice affixed to any distribution by the recipient that contains a |
---|
| 548 | copy or derivative of this software. |
---|