From: David Robinson (David.Robinson@sun.com)
Date: 01/22/03-02:45:59 PM Z
Message-Id: <200301222046.h0MKk0L15771@phys-hanwk16-1.ebay.sun.com> Date: Wed, 22 Jan 2003 14:45:59 -0600 (CST) From: David Robinson <David.Robinson@sun.com> Subject: Re: NFSv4 Advisory vs. Mandatory locking issues I have trouble with the notion of "implicit locking." NFSv4 has no such notion and an I/O operation should not fail wity NFS4ERR_LOCKED unless there is an explicit lock. Internally many implementations will acquire a per file mutex to serialize I/O requests necessary for some file system semantics such as those specified by POSIX. However, the serialization should only cause an increase in latency for the reply to the client, not an error. Realistically the NFSv4 server has only two choices: 1) Implement advisory locking which allows I/O to complete even in the face of a "conflicting" lock 2) Implement mandatory locking, causing I/O operations to error if an explicit lock conflicts. There is no third choice of having the server obtain implicit locks. If you have a client OS that maintains the model that all I/O operations occur only within the control of a lock, I would suggest that the solution should be implemented on the client. For all I/O requests, form a COMPOUND operation that obtains the necessary lock, does I/O and unlocks. For example <PUTFH, LOCK, READ, LOCKU>. While this will not prevent an uncooperative client from doing I/O without a lock, through export/share controls you can limit those clients from having access. The advantage is that your application will get the right semantics with a standard server. With this approach, you could add the non-standard feature to the server that it will reject any I/O that is not done within an explicit lock range. This will of course break standard client's access, but it is much more civilized than trying to implement "implicit" locks. The latter will result in a standard client seeing some operations suceed and some fail depending on what other I/O operations are being performed, even in the abscence of explicit locks. With this non-standard feature all I/Os will deterministically fail without an explicit lock. For non-standard features, this is the lesser of two evils. -David
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:47 AM Z CST