From: Mike Eisler (mike@eisler.com)
Date: 01/18/03-10:07:20 AM Z
Message-ID: <3E297BB8.7030202@eisler.com> Date: Sat, 18 Jan 2003 08:07:20 -0800 From: Mike Eisler <mike@eisler.com> Subject: Re: Mandatory vs. Advisory David Robinson wrote: > Stevan Steve Allen wrote: > >> I believe your prior post describes a basic environment where >> applications >> decide if locking (control) is needed and there is no checking by the >> pfs >> level or file server. In this environment, locking is never required by >> the pfs/file server to access data (hence nothing to do with data >> integrity). The NFS supported locking model does not provide data >> integrity, instead it is a communication vehicle for remote >> applications to >> control each other. Customers may attempt<?> to impose data >> integrity by >> controlling access to only those applications which provide the >> necessary >> lock requests for the level of integrity needed by the customer >> solution. > > > Maybe it will help to describe an example of how NFSv4 cannot provide > data integrity unless all applications are cooperating. Two processes > are working on a file, both have the file open read/write and also > allow other read/writers (otherwise both couldn't have gotten two > read/write access). In sharing the file each process grabs the > necessary write lock before it modifies the data and drops it when > finished to allow the other process to have access. In the mandatory > locking model, the process can either grab the explicit lock which will > guarentee read access without concern for an interposing write, or it > can simply read the data and if there is a conflicting lock the read > will return an error and the process can decide how to proceed (i.e. > error, sleep and retry, whatever). But even in the case of two > cooperating processes, each explicitly grabbing locks before doing an > I/O, which makes the data between them consistent, there is still the > issue of a third process opening the file and causing corruption. > Because the act of unlocking part of a file and allowing another to grab > a lock is not atomic, the third process can get an operation in > (possibly an I/O without a lock being held) that will corrupt the data. > > At best, NFSv4 can only use access control to restrict who > can OPEN a file and thus get access to a file. I agree, but your example applies to three processes on the same system each accessing the same file on the same local filesystem. > > >> I have Brent's illustrated book (which we seem to have >> misinterpreted), do >> you recommend any other material describing the control model you >> mention? > > > The NFSv4 locking model is a hybrid of the standard POSIX advisory > locking model and the Windows file locking model. It does not however > incorporate the SYS V mandatory locking model. Reading publications > on those is probably your best bet. I disagree. I think the System V mandatory locking model is supportable. When the server performs aconflicting I/O on a file with the mandatory lock bit set, it can use the stateid of the request to see if the requester has the conflicting lock. If the requester has the conflicting lock, and the lock doesn't need to be upgraded (e.g. read to write, range extension), then the server can allow the I/O. Otherwise, it can simply return NFS4ERR_LOCKED, and the client can then acquire the necessary lock on behalf of its process. At least this was how RFS worked in System V Release 3.2. Since the System V Verification Suite (SVVS) passed on System V R3.2 over RFS (and not on System V R3.0), I conclude that an NFSv4 client and server implementing System mandatory locking would pass SVVS. And that's good enough proof that NFSv4 supports System V mandatory locking. BTW, this issue was discussed at length at the Ann Arbor bakeoff last August, and as a result, text was added to the specification to clarifiy, as well as eliminating the rather useless mandatory lock flag from the OPEN results. (It was eliminated because in the System V world, the mand lock bit can come on any time. Therefore, NFS4ERR_LOCKED is the only consistent indicator that mandatory locking is on. See http://www.nfsv4.org/rfc3010updates/issue218/issue218.html I don't know what Stevan's client's locking model is, but if the client represents a significant platform in terms of numbers of users (given the number of different platforms IBM has, and the size of IBM's business, a real possibility), future minor revisions of NFSv4 ought to consider extending NFSv4 locking accordingly, if it is feasible.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:47 AM Z CST