Messages in this thread | | | Subject | flock affects local node only traditionally and applications expect | From | Steve French <> | Date | 31 Aug 2004 15:25:29 -0500 |
| |
> flock affects local node only traditionally and applications > expect high performance from it. Our documentation merely says > > flock(2) does not lock files over NFS.Use fcntl(2) instead:
I remember, in the days before Linux (BL), when the only apps that cared about file locking were the ones running over the (and not just Novell, DOS, OS/2, Windows) networks (because local apps had other mechanisms to serialize but it was one of the few decent ways to serialize when you had an app run from multiple clients at the same time) ...
The man page also notes that in earlier versions of Linux that flock used to work over the network (since it used to be mapped to fcntl), but I read the reasons for the change as a semantic issue between BSD/POSIX locks. If the real issue is instead performance issues then individual filesystems could make it a mount option for NFS, CIFS, GFS or any other filesystem that wants to map them to support local semantics. But given the increase in network performance, why not optionally allow flock - it is reasonable to assume that some users have apps that would benefit from local file lock semantics over the network and that we should allow users to experience (as close to) local semantics over network filesystems as the corresponding network protocol (over the wire) could allow (at least as a mount option). I am curious what the other Samba guys think about adding this minor optional extension to the wire protocol.
The other issue that came up in the earlier discussion of these was Ken's question about why should the client VFS manage a local copy of the lock when the server side already will be doing that. The client VFS has to be able to keep the lock state to attempt to replay locks on a server crash, but the VFS on the client machine would not have to enforce the lock semantics - not just because redundancy may slow things down (that is a trivial performance penalty) but since the client copy of the lock state will often be stale if multiple clients are locking the file. For mandatory locks the correct semantics are more difficult to enforce (only) on the server since reads/writes frequently go to the copy of the data in the local page cache and never make it to the server.
Also ... is there a good writeup on any subtle semantic differences between flock and fcntl locks?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |