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-2033 Lustre <p>With patches from Orion branch landed to master, some new local files (such as seq-xxx-lastid) are created on the MDT, which FIDs are not normal but inserted into OI files.</p> <p>Lustre uses these files through lookup-by-FID, which will cause failure after the MDT restored from file-level backup, if we specify "noscrub" option when mount the MDT.</p> LU-2033

MDT cannot mount after restored from file-level backup if the mount option "noscrub" specified

Bug Blocker Resolved Fixed nasf nasf Wed, 26 Sep 2012 12:44:46 +0000 Wed, 24 Apr 2013 17:32:01 +0000 Mon, 8 Oct 2012 10:38:38 +0000 Lustre 2.4.0 Lustre 2.4.0 0 6 <p>I'd say that be able to lookup by FID is important from the overall design point of view. the whole problem of maintaing OI and doing this timely belongs to specific OSD and it's responsibility of OSD to address this properly. otherwise we're overloading the API with some very specific details making the life of Lustre service's developers hard..</p> <p>Hm... that depends on how the lookup-by-FID works. I prefer to use the OSD layer per-thread FID &lt;=&gt; ino# cache to partly support the lookup-by-FID for these special local files. Means the initial lookup should be by name, and cache related FID &lt;=&gt; ino# mapping, then subsequent lookup-by-FID can work.</p> <p>This is a workable patch:</p> <p><a href="http://review.whamcloud.com/#change,4106" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,4106</a></p> <p>I disagree. as I said above, this is an extra requirement which pretty much rush the idea behind OSD API... </p> <p>If without object name knowledge, I do not think OSD can resolve that totally by itself inside. It may be work for ZFS backend, but does not work for current ldiskfs backend. I do not think you will like the idea to change lookup-by-FID interfaces to pass some name related hint for that.</p> <p>In this case, what is the reason for the MGS must call lookup-by-FID for the special local file "seq-xxx-lastid", why not lookup-by-name?</p> <p>I agree with you that it will be much helpful for the developer that if the OSD can properly process lookup-by-FID internally, in spite of whether the device restored from file-level backup or not, but current osd-ldiskfs OI design does not support it, that is why we did OI scrub. Changing current osd-ldiskfs OI design and implementation will not be small work, and will introduce some compatibility issues. I do not think we can do that is a short time. From a long view, we maybe can do. But as a workable solution, I more like using lookup-by-name for the MGS to locate "seq-xxx-lastid".</p> <p>So is b2_3 really affected? I just did a quick grep for -lastid in the code and there are no matches, also there are no orion landings in b2_3</p> <p>no, 2.3 is not affected.</p> <p><a href="http://review.whamcloud.com/#change,4106" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,4106</a> landed to master</p> Duplicate LU-2103 LU-3213 Development Rank 1|hzv413: Rank (Obsolete) 4183 Severity