[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:
Related
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:
1. objects with pre-defined FID, they get names via osd_compat_spec code, which assigns names for hardcoded FIDs.
2. files created with generated FIDs, usually with name but can be just objects disconnected from namespace. They are going through OI now.

There are two orthogonal problems:
1. local object must be linked to namespace. Some are created just as objects by FID, so name should be created by OSD for compatibility/lfsck reasons
2. local object shouldn't be in OI so server can mount without OI.

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.
2. Di patch is needed for dynamic O/seq/dN creation beyond current MAX_OBJID_GROUP limit.
3. Don't insert local objects to the OI but use osd_compat_objid_ methods to create names in O/seq/dN excluding directories.
4. Make sure there is no way to create nameless local directory
5. All fid-inode translation for local objects are done via name lookup, in fact we could use O/seq/dN as well but not for directories.



 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.

3. Don't insert local objects to the OI but use osd_compat_objid_ methods to create names in O/seq/dN excluding directories.

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?

4. Make sure there is no way to create nameless local directory

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, ORI-363 and ORI-362.

Comment by Mikhail Pershin [ 11/Apr/14 ]

this issue was solved during the lfsck project

Generated at Sat Feb 10 01:24:23 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.