[LU-8848] create may send MDS_REINT/REINT_CREATE and LDLM_ENQUEUE/REINT_OPEN Created: 17/Nov/16  Updated: 17/Nov/16

Status: Open
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: John Hammond Assignee: Oleg Drokin
Resolution: Unresolved Votes: 0
Labels: llite

Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

[8:56:48 AM] John Hammond: On RHEL 6, assume that the file f0 is does not exist. If we do stat(f0) followed by creat(f0) then the create sends a MDS_REINT/REINT_CREATE from ll_create_nd() followed by a LDLM_ENQUEUE/REINT_OPEN from ll_file_open(). I don't think it was always this way. Am I wrong? If not then do you know when it changed?
[9:54:50 AM] Oleg Drokin: hm, it should not work like that. is this master? EE of some sort? Related patches were in the opencache, first the improper fix in LU-4367 and then proper in LU-8019
[9:55:45 AM] John Hammond: This is in master on 2.6.32-573.12.1.el6_lustre.g74ae81d.x86_64. (HAVE_IOP_ATOMIC_OPEN is not defined.)
[9:57:46 AM] Oleg Drokin: So in ll_revalidate_dentry we should get this code run:
[9:57:46 AM] Oleg Drokin: + /*
+ * if open&create is set, talk to MDS to make sure file is created if
+ * necessary, because we can't do this in ->open() later since that's
+ * called on an inode. return 0 here to let lookup to handle this.
+ */
+ if ((lookup_flags & (LOOKUP_OPEN | LOOKUP_CREATE)) ==
+ (LOOKUP_OPEN | LOOKUP_CREATE))
[9:58:07 AM] Oleg Drokin: this would return 0 meaning revaliate fails
[9:58:49 AM] Oleg Drokin: then we should not get into create(), but should get into ->lookup() in our code first
[10:00:13 AM] Oleg Drokin: ah, LU-8371 removed that
[10:00:56 AM] Oleg Drokin: I guess that did fail to take into account older kernels
[10:01:42 AM] Oleg Drokin: though rhel6.x is not really supposed to be supported on master anymore, but we probabl can reinstate some of that logic just in rhel6 specific path when IOP_ATOMIC_OPEN is not defined
[10:04:06 AM] John Hammond: Well we don't have HAVE_IOP_ATOMIC_OPEN until 3.6.



 Comments   
Comment by Jinshan Xiong (Inactive) [ 17/Nov/16 ]

Do we really need to handle LOOKUP_REVAL in ll_revalidate_dentry() as dentries in LLITE is protected by a lock?

Generated at Sat Feb 10 02:21:04 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.