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

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.4.0
• Affects Version/s: Lustre 2.4.0
• Severity: 3
• Assignee: nasf (Inactive)
• Reporter: nasf (Inactive)

Description

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.

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.

Issue Links

• is duplicated by: LU-2103 sanity-scrub fails and causes all following tests to fail.
• is duplicated by: LU-3213 Interop 2.3.0<->2.4 failure on test suite sanity-scrub test_11: (5) Expect 101 objects skipped, but got 107

Comments

[Ian Colle (Inactive)]

http://review.whamcloud.com/#change,4106 landed to master

[Alex Zhuravlev]

no, 2.3 is not affected.

[Oleg Drokin]

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

[nasf (Inactive)]

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.

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?

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".

[Alex Zhuravlev]

I disagree. as I said above, this is an extra requirement which pretty much rush the idea behind OSD API...

[nasf (Inactive)]

Hm... that depends on how the lookup-by-FID works. I prefer to use the OSD layer per-thread FID <=> 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 <=> ino# mapping, then subsequent lookup-by-FID can work.

This is a workable patch:

http://review.whamcloud.com/#change,4106

[Alex Zhuravlev]

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..