https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3299 Lustre <p>When a file is restored the layout lock is first<br/> associated with the released layout and after restore<br/> it has to be associated with the new layout. This patch<br/> forces lvb_data update in ll_layout_fetch() even if one<br/> is present (case for released-&gt;normal state change).</p> LU-3299

force lvb_data update after layout change

Bug Blocker Resolved Fixed Jinshan Xiong CEA patch Wed, 8 May 2013 20:30:58 +0000 Wed, 5 Aug 2020 13:32:56 +0000 Tue, 18 Jun 2013 15:30:19 +0000 Lustre 2.5.0 Lustre 2.5.0 0 4 <p>I think we should stop using LVB for this purpose on the both sides.</p> <p>This is to track the bug we found when porting HSM to master (see <a href="https://jira.whamcloud.com/browse/LU-3280" title="when lock-&gt;l_lvb_data is freed, LDLM_FL_LVB_READY is not cleared" class="issue-link" data-issue-key="LU-3280"><del>LU-3280</del></a>). The patch is at <a href="http://review.whamcloud.com/6291" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6291</a><br/> No need to review yet, this is just to keep trace.</p> <p>This is for 2.5</p> <p>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.</p> <p>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.<br/> 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.<br/> and I don't quite see why do we need LVB_READY given the layout can't fit LVB sometimes and we <b>have to</b> use regular xattrget, which is correct and should be used for any size in general. the less special cases, the better.</p> <blockquote> <p> and in my mind LDLM locking should be separated from storage access as much as possible</p></blockquote> <p>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?</p> <blockquote> <ul class="alternate" type="square"> <li>all I need is to be able to get the layout as a regular extended attribute.</li> </ul> </blockquote> <p>I agree.</p> <blockquote> <p>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.</p></blockquote> <p>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.</p> <p>When you're writing if-clause in the code, actually you're having a special case, sigh <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>given frequency of layout changes I tend to think this is baraly visible optimization, to be honest.</p> <p>Closing ticket since patch has landed to Master. PLease let me know if additional work is needed and I will reopen the ticket.</p> Development Epic client Rank 1|hzvqgv: Rank (Obsolete) 8166 Severity