[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-nfs
Subject:    [NFS] safely updating nfs exported files
From:       ahoward <ahoward () fsl ! noaa ! gov>
Date:       2003-02-18 16:15:30
[Download RAW message or body]



nfs'ers-

i'm deliberating two methods of updating nfs exported files read by our
near-realtime linux clients and written by a single updating process :

  a)  some combination of locking, probably using ${file}.lock and fcntl
  read/write locks to protect the file during update

  b) a combination of 'mv update nfs.tmp; mv update nfs.prev; mv nfs.tmp nfs'
  in the updating processes and fault tolerance code in the reading clients
  which will attempt to open files > once so that during the brief spell when
  the file is not available (mv update nfs.prev) failed opens will be retried.

my environment is primarily linux clients running against a netapp server -
nfsV3.  however, there are other legacy OS's which will also need to use
whatever mechanism i come up with (IRIX, HP-UX, Solaris, etc) and thus i am
leaning towards solution 'b' since it requires only that clients be prepared
to attempt opens > once and yet multiple reader single writer semantics are
preserved without the use of locks (and their problems).  does anyone have
opiions on this?  other suggestions?

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
[prev in list] [next in list] [prev in thread] [next in thread]