[LU-5676] DNE 2: cache LMV EA in LOD Created: 27/Sep/14 Updated: 28/Feb/20 Resolved: 28/Feb/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | nasf (Inactive) | Assignee: | Di Wang |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Severity: | 3 | ||||||||||||||||
| Rank (Obsolete): | 15898 | ||||||||||||||||
| Description |
|
For a striped directory, the on-disk master LMV EA only contains the header information, not contains the FIDs of the shards. When some thread tries to access the master LMV EA, it will trigger the iteration against all the shards to collect the FID of each shard to compose of the integrated master LMV EA. Currently, we have no cache for the master LMV EA in LOD, then it will cause iteration every time when the master LMV EA accessed. To avoid that, we can cache the master LMV EA in LOD. |
| Comments |
| Comment by Andreas Dilger [ 27/Sep/14 ] |
|
This isn't really an LFSCK 3 debt, but rather one for DNE 2. |
| Comment by Di Wang [ 30/Sep/14 ] |
|
nasf: could you please check the patch in |
| Comment by nasf (Inactive) [ 30/Sep/14 ] |
|
Di: which patch you mean? I only saw one patch (http://review.whamcloud.com/#/c/10376/) mentioned in |
| Comment by nasf (Inactive) [ 03/Nov/14 ] |
|
Di: opening this ticket is NOT because some bad test results we have ever observed. I do not think |
| Comment by Andreas Dilger [ 28/Feb/20 ] |
|
I believe this was implemented as part of |