aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorOleg Drokin <oleg.drokin@intel.com>2017-01-28 19:04:54 -0500
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-02-03 07:01:37 -0500
commitd9421ff6c1998f2e4d829e571bbbd531ffd85e6f (patch)
treeedff8b4b8b9204d6e0a1fae1fb2f8696a01da0da
parente27bcd66cb84b67a1231e5c6245673826673b66d (diff)
staging: lustre: 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). Signed-off-by: Oleg Drokin <oleg.drokin@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8371 Reviewed-on: http://review.whamcloud.com/21168 Reviewed-by: James Simmons <uja.ornl@yahoo.com> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-rw-r--r--drivers/staging/lustre/lustre/llite/dcache.c13
-rw-r--r--drivers/staging/lustre/lustre/llite/file.c11
2 files changed, 16 insertions, 8 deletions
diff --git a/drivers/staging/lustre/lustre/llite/dcache.c b/drivers/staging/lustre/lustre/llite/dcache.c
index 65bf0c401b44..966f580e26fb 100644
--- a/drivers/staging/lustre/lustre/llite/dcache.c
+++ b/drivers/staging/lustre/lustre/llite/dcache.c
@@ -247,17 +247,14 @@ static int ll_revalidate_dentry(struct dentry *dentry,
247 return 1; 247 return 1;
248 248
249 /* 249 /*
250 * if open&create is set, talk to MDS to make sure file is created if 250 * VFS warns us that this is the second go around and previous
251 * necessary, because we can't do this in ->open() later since that's 251 * operation failed (most likely open|creat), so this time
252 * called on an inode. return 0 here to let lookup to handle this. 252 * we better talk to the server via the lookup path by name,
253 * not by fid.
253 */ 254 */
254 if ((lookup_flags & (LOOKUP_OPEN | LOOKUP_CREATE)) == 255 if (lookup_flags & LOOKUP_REVAL)
255 (LOOKUP_OPEN | LOOKUP_CREATE))
256 return 0; 256 return 0;
257 257
258 if (lookup_flags & (LOOKUP_PARENT | LOOKUP_OPEN | LOOKUP_CREATE))
259 return 1;
260
261 if (!dentry_may_statahead(dir, dentry)) 258 if (!dentry_may_statahead(dir, dentry))
262 return 1; 259 return 1;
263 260
diff --git a/drivers/staging/lustre/lustre/llite/file.c b/drivers/staging/lustre/lustre/llite/file.c
index a1e51a54779e..987090119559 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -417,6 +417,17 @@ out:
417 ptlrpc_req_finished(req); 417 ptlrpc_req_finished(req);
418 ll_intent_drop_lock(itp); 418 ll_intent_drop_lock(itp);
419 419
420 /*
421 * We did open by fid, but by the time we got to the server,
422 * the object disappeared. If this is a create, we cannot really
423 * tell the userspace that the file it was trying to create
424 * does not exist. Instead let's return -ESTALE, and the VFS will
425 * retry the create with LOOKUP_REVAL that we are going to catch
426 * in ll_revalidate_dentry() and use lookup then.
427 */
428 if (rc == -ENOENT && itp->it_op & IT_CREAT)
429 rc = -ESTALE;
430
420 return rc; 431 return rc;
421} 432}
422 433