On Tue, 2018-09-11 at 16:47 -0400, Chris Siebenmann wrote: > > > > Pragmatically, Alpine used to work with NFS mounted filesystems > > > > where > > > > email was appended to them from other machines and it no longer > > > > does, > > > > and the only difference is the kernel version involved on the > > > > client. > > > > This breakage is actively dangerous. > > > > > > Sure, but unless you are locking the file, or you are explicitly > > > using > > > O_DIRECT to do uncached I/O, then you are in violation of the > > > close-to- > > > open consistency model, and the client is going to behave as you > > > describe above. NFS uses a distributed filesystem model, not a > > > clustered one. > > > > I would expect Alpine to work if "vers=3,noac" is in use. > > We're setting noac (and vers=3) for our /var/mail NFS mount, but > perhaps we've got some additional option that is wrong here and > should be changed? According to /proc/mounts, our mount settings > for /var/mail are: > > fs0.cs.toronto.edu:/cs/mail /var/mail nfs > rw,sync,nosuid,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,naml > en=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,noacl,pr > oto=tcp,timeo=11,retrans=4,sec=sys,mountaddr=128.100.3.130,mountvers= > 3,mountport=34630,mountproto=udp,local_lock=none,addr=128.100.3.130 > This has nothing to do with mount options. Buffered reads of a file that is being written to over NFS without using locking is inherently unsafe. That always has been the case... Both writes and reads can be reordered by the RPC layer on both the client and the server, and they can be further reordered by the NFS layer on the server. In practice, this means that you can find yourself reading parts of the file that have not yet completed being written to, because, for example, a write that extended the file from offset 4096- 8191 completed before the write that was supposed to extend it from offset 0-4095 was processed by the server. This is true with or without noac... -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
