Whamcloud - gitweb
LU-8371 llite: Trust creates in revalidate too. 68/21168/5
authorOleg Drokin <oleg.drokin@intel.com>
Wed, 6 Jul 2016 04:38:19 +0000 (00:38 -0400)
committerOleg Drokin <oleg.drokin@intel.com>
Mon, 22 Aug 2016 03:45:55 +0000 (03:45 +0000)
commit9573911bfb4a2c3d7e2047c9d5f5440d9c7e7db5
tree344cdc63c985f7339eccdc617b857ad4620eb3e0
parent81eea4b470a6ff45478f92659389ad8cb0277415
LU-8371 llite: Trust creates in revalidate too.

By forcing creates to always go via lookup we lose some
important caching benefits too.
Instead let's trust creates with positive cached entries.

Then we have 3 possible outcomes:
1. Negative dentry - we go via atomic_open and do the create
   by name there.
2. Positive dentry, no contention - we just go straight to
   ll_intent_file_open and open by fid.
3. positive dentry, contention - by the time we reach the server,
   the inode is gone. We get ENOENT which is unacceptable to return
   from create. But since we know it's a create, we substitute it
   with ESTALE and VFS retries again with LOOKUP_REVAL set, we catch
   that in revalidate and force a lookup (same path as before this
   patch).

Change-Id: I7b006a50703bfb37e8747dca0f95b2c512b82429
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Reviewed-on: http://review.whamcloud.com/21168
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
lustre/llite/dcache.c
lustre/llite/file.c