3 ms·
> Unfortunately, this change creates another surprising situation, which is that the NFS server and a NFS client can both obtain an exclusive flock() lock on th
by cryptonector 4y ago
> Unfortunately, this change creates another surprising situation, which is that the NFS server and a NFS client can both obtain an exclusive flock() lock on the same file. Two NFS clients trying to exclusively flock() the same file will conflict with each other and only one will succeed, but the NFS server and an NFS client won't, and both will 'win' the lock (and everyone loses). This is the inevitable but surprising consequence of client side flock() locks being changed to POSIX locks on the NFS server, and POSIX locks not conflicting with flock() locks. From the NFS server's perspective, it's not two flock() exclusive locks on a file; it's one exclusive POSIX lock (from a NFS client) and one exclusive local flock() lock, and that's nominally fine.
One might say "right, so don't run apps on the file server", but if the file server is running multiple file server protocols some of which want to locally flock(), then you lose unless flocks and POSIX locks are made to conflict.
So either rip out this feature of the NFS client on Linux or make local flock locks and POSIX locks conflict at the very least if the filesystem is shared via NFS.
- marcosdumay 3y agoDoesn't it all just solve itself if you let the original data unused and mount the root of all those file servers through NFS? You don't need the extreme of not running anything else on the server. You just need to not get it access to the original files.
- cryptonector 3y agoSort of. Suppose you want to run Samba or WebDAV or whatever to export the same filesystems over something other than NFS. You could export remote shares, I suppose, but the obvious thing to do is to export local filesystems on the server, but now if smbd or whatever wants to use flock(), you have a problem.