[LU-3299] force lvb_data update after layout change

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.0
• Fix Version/s: Lustre 2.5.0
• Type: Bug
• Priority: Blocker
• Reporter: CEA
• Assignee: Jinshan Xiong (Inactive)
• Resolution: Fixed
• Labels: patch
• Severity: 3
• Epic: client

Description

When a file is restored the layout lock is first
associated with the released layout and after restore
it has to be associated with the new layout. This patch
forces lvb_data update in ll_layout_fetch() even if one
is present (case for released->normal state change).

Comments

[Alex Zhuravlev]

I think we should stop using LVB for this purpose on the both sides.

[jacques-charles lafoucriere]

This is to track the bug we found when porting HSM to master (see LU-3280). The patch is at http://review.whamcloud.com/6291
No need to review yet, this is just to keep trace.

[Jodi Levi (Inactive)]

This is for 2.5

[Jinshan Xiong (Inactive)]

Hi Alex, what's wrong with using LVB to store layout here? From my understanding, it matches the semantics of LVB very well. Needless to say we have to use LVB_READY bit in ldlm lock.

[Alex Zhuravlev]

I don't think it matches LVB well... and in my mind LDLM locking should be separated from storage access as much as possible. this gives us possibility to use different locking (or no locking) in different cases.
Like, for example, if I create a directory, hold an exclusive lock on that directory, I can create files in that directory locally, with no LDLM/MDC involved at all - all I need is to be able to get the layout as a regular extended attribute.
and I don't quite see why do we need LVB_READY given the layout can't fit LVB sometimes and we have to use regular xattrget, which is correct and should be used for any size in general. the less special cases, the better.

[Jinshan Xiong (Inactive)]

and in my mind LDLM locking should be separated from storage access as much as possible

This is actually a very strong requirement. Servers own resources and if we want to cache it on the client, a lock is necessary. Resources are usually a state in persistent storage. For example, the resource of an extent lock is a set of disk blocks the extent covers. Ah maybe what you meant is to not access storage so that they must be in memory cache for DLM code path?

• all I need is to be able to get the layout as a regular extended attribute.

I agree.

and I don't quite see why do we need LVB_READY given the layout can't fit LVB sometimes and we have to use regular xattrget, which is correct and should be used for any size in general. the less special cases, the better.

This is a good question. I think this is for optimization - the root of all evil. If we could preallocate all LVB buffer with maximum size, then it would fit. We don't do this because we don't want to waste so much memory.

When you're writing if-clause in the code, actually you're having a special case, sigh

[Alex Zhuravlev]

given frequency of layout changes I tend to think this is baraly visible optimization, to be honest.

[Jodi Levi (Inactive)]

Closing ticket since patch has landed to Master. PLease let me know if additional work is needed and I will reopen the ticket.