[LU-2033] MDT cannot mount after restored from file-level backup if the mount option "noscrub" specified Created: 26/Sep/12 Updated: 24/Apr/13 Resolved: 08/Oct/12 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.4.0 |
| Fix Version/s: | Lustre 2.4.0 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | nasf (Inactive) | Assignee: | nasf (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Severity: | 3 | ||||||||||||
| Rank (Obsolete): | 4183 | ||||||||||||
| 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. |
| Comments |
| Comment by Alex Zhuravlev [ 26/Sep/12 ] |
|
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.. |
| Comment by nasf (Inactive) [ 26/Sep/12 ] |
|
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: |
| Comment by Alex Zhuravlev [ 26/Sep/12 ] |
|
I disagree. as I said above, this is an extra requirement which pretty much rush the idea behind OSD API... |
| Comment by nasf (Inactive) [ 26/Sep/12 ] |
|
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". |
| Comment by Oleg Drokin [ 27/Sep/12 ] |
|
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 |
| Comment by Alex Zhuravlev [ 27/Sep/12 ] |
|
no, 2.3 is not affected. |
| Comment by Ian Colle (Inactive) [ 07/Oct/12 ] |
|
http://review.whamcloud.com/#change,4106 landed to master |