Re: New client-side locking implementation
Matt Benjamin <[email protected]>
| Newsgroups | gmane.comp.file-systems.openafs.devel.win32 |
|---|---|
| Message-ID | <[email protected]> |
Jeffrey Altman wrote: >Eric Williams wrote: > > >Eric: > >I wanted to come back to this portion of the thread for a few minutes. >Given that the Windows locking model is "mandatory", do you have a >proposal for how "advisory locking" could be used while still >maintaining data integrity? > >Jeffrey Altman > > Jeff, I said what I said originally only to get some things cleared up, eg, wrt byte-range locks you can take out on the existing client. I don't think Eric has any such suggestion? As you stated, the model on Windows is mandatory, notwithstanding, I am no expert on Windows behaviors or APIs. Unless I mistake myself again, you don't get data integrity on Windows with an advisory model, simply because clients are written to expect this behavior. I can't imagine the first thing a Windows programmer does when he can't lock a byte-range, is write in it. Therefore, I surmise that advisory range locking, with whole-file lock in AFS, might actually improve the behavior of some clients. I am not suggesting that this would be desirable. Are you speculating that it would? The last bit of your original message addressed itself to posix locking. I haven't read the nfsv4 wg posts; however, the posix locking model is advisory. I believe it is established that cooperating applications can provide data integrity in the posix model using fcntl (or lockf) and fsync/fdatasync. Of course, uncooperative clients with correct permissions can do what they like to locked files. The advisory model considers this not a violation of data integrity, but a permissions or application problem. Matt -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309