On Thu, Aug 21, 2014 at 11:40 AM, David Jeffery <djeffery@xxxxxxxxxx> wrote: > On 08/20/2014 08:28 PM, Trond Myklebust wrote: >> >> What guarantees that this does not lead to silent corruption of the file >> if there are outstanding write requests? >> > > Do you have a particular scenario in mind you are concerned about? > > Right before the code the patch modifies, nfs_sync_mapping() is called. > Any writes started before the unlock operation began have already been > flushed, so we shouldn't have a corruption case of writes from before > the unlock began being sent after the unlock is complete. > > Are you concerned about some other nfs4 writes being started while we > initially waited on the counter? Such a write racing with the unlock No. I'm worried about the writes that have been started, but which are now completing in the background while the lock is being freed. > going ahead instead of erroring out could initially fail from a wrong > state ID, but should retry with the new state. Is there something I've > overlooked? Loss of lock atomicity due to the fact that the writes are completing after the lock was released. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
