5

I'm planning on having a complicated file sharing setup, and want to make sure I don't destroy file locking. (Wanting to use bind mounting, nfs, nfs over rdma (InfiniBand file sharing), and virtfs (kvm virtual machine pass-through file sharing) on the same data.)

I'm at the beginning sanity checks, just testing the nfs server with a single nfs client. Up to date Arch on both systems, nfs-utils 1.3.2-6, kernel 4.1.6-1.

I'm seeing unexpected results. On the nfs server:

server exports with: /test 192.168.0.0/16(rw,sync,no_subtree_check,
   no_root_squash)
client mount shows: 192.168.1.2:/test on /test type nfs4 (rw,noatime,vers=4.2,
   rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,
   retrans=2,sec=sys,clientaddr=192.168.1.3,local_lock=none,addr=192.168.1.2)

In /test, I have a script named lockFile with contents:

#!/bin/bash
filename="lockedFile"
exec 200>$filename
flock -n 200 || exit 1
pid=$$
while true; do
   echo $pid 1>&200
done

If I use two terminals on the nfs server:

1: ./lockFile
2: ./lockFile

Then, terminal 1 quickly fills up a file with its pid, and terminal 2 immediately exits. All as expected.

But, if I run a terminal each on the nfs server and client:

server: ./lockFile
client: ./lockFile

They both happily run, very unexpected.

In this configuration, my nfs server is running as sync, meaning the server only says data is written when it is actually written. My nfs client is running as async, meaning the client only transmits the writes when the file is closed.

I could see the client running async perhaps not obtaining a lock until it actually transmits the writes, so I tested this, changing the client to sync.

client mount now shows: 192.168.1.2:/test on /test type nfs4 (rw,noatime,sync,
   vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,
   retrans=2,sec=sys,clientaddr=192.168.1.3,local_lock=none,addr=192.168.1.2)

Still lockFile happily runs on both machines.

Am I misunderstanding how NFS file locking is expected to work? Is it expected to handle server access vs client access? Or, is it just for client access vs different client access?

Improve this question

1 Answer 1

Reset to default
6

flock doesn't work over NFS. (It never has, even on UNIX systems.)

See flock vs lockf on Linux for one comparison of lockf and flock.

Here is a possible solution Correct locking in shell scripts?

Improve this answer
3
  • 1
    You nailed it. Wrote a c app that uses lockf, and terminal 2 now complains like it should.
    – user1902689
    Sep 14, 2015 at 22:39
  • That's not what's here: serverfault.com/a/692982/306772 "Since Linux 2.6.12, NFS clients support flock() locks by emulating them as byte-range locks on the entire file."
    – Rodrigo
    Jul 25, 2016 at 14:31
  • 1
    @Rodrigo I hear you. However, the solution suggested in your link doesn't work with flock(). It does work with lockf(). I am running rpc.statd with NFS3 on "recent enough" kernels.
    – roaima
    Jul 25, 2016 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .