[LU-2340] Storing server local files Created: 05/Apr/12 Updated: 11/Apr/14 Resolved: 11/Apr/14 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Major |
| Reporter: | Mikhail Pershin | Assignee: | Mikhail Pershin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||
| Story Points: | 3 | ||||
| Project: | Orion | ||||
| Rank (Obsolete): | 2973 | ||||
| Description |
|
The server local files shouldn't be added into OI, so they would be restored and used upon mount even without OI. These files also must be linked in namespace if have no name. There are two types of local files: There are two orthogonal problems: As solution we could say that all local object must be linked to O/seq/ directories. So problem (1) is solved. But we cannot hadrlink directories and already named files will get second link. That restricts us to the following - all local objects are linked to O/ except directories and no directory can be created without name. Having 2 links for regular file is not a big problem. The problems to solve: 1. for osd_compat_spec object-name table - all pre-defined FIDs must have name, now it is not so, e.g. PENDING is created by fixed FID but MDD also creates name, this is not correct, if FID is fixed than it is enough to find PENDING for MDD, if MDD uses name then fixed FID is not needed. |
| Comments |
| Comment by Li Wei (Inactive) [ 05/Apr/12 ] |
|
The new design unifies how FID_SEQ_LOCAL_FILE, FID_SEQ_LLOG, and IDIF objects are handled, making the logic easier to remember. Looks good to me.
Perhaps it's also the time to clean up the names in those functions, as they are no longer only for OST and compatibility purposes?
Interestingly, this might open a door for OSD to detect creations of nameless objects and assign internal names if appropriate, so that all "local" objects have exactly one name. In theory, the detection could happen at transaction start time, with its decision saved under transaction handles. Another benefit is that, during object creation declarations, osd-ldiskfs no longer has to always reserve name insertion credits, and osd-zfs no longer has to compute zapid again after transaction start. |
| Comment by Li Wei (Inactive) [ 17/Oct/12 ] |
|
What is the plan for this one? It was blocking ORI-577 and, to a lesser degree, |
| Comment by Mikhail Pershin [ 11/Apr/14 ] |
|
this issue was solved during the lfsck project |