[LU-1866] LFSCK Phase 1.5 for FID-in-dirent and linkEA consistency

Related — Wed, 18 Jun 2014 22:20:21 +0000

In Lustre-2.x, when create a file, its FID (File IDentifier) is stored as part of the name entry in the parent directory, which is called FID-in-dirent. With the FID-in-dirent, readdir on the MDT can fetch the FID from the directory page directly instead of having to get it from the object LMA (Lustre Metadata Attributes) extended attribute stored on the inode. As a result, traversing the directory (such as "ls") with FID-in-dirent is much faster than having to access the FID from the LMA. Also at file creation time, the FID of the parent directory and the name of the file are stored in the linkEA extended attribute on the inode. With the linkEA, any given FID can be parsed back to a full path from the root directory to the target file. It is useful for those ChangeLog based applications, like "lustre_rsync" and when generating error messages or POSIX style pathname permission checks. Hard links to a regular file also create the same FID-in-dirent and linkEA attributes to be stored.

Over the lifetime of an active filesystem, some FID-in-dirent and linkEA may become inconsistent or invalid as the result of on-disk corruption, after restoring from MDT file-level backup, or if the MDT filesystem was originally formatted under Lustre 1.8. Currently, if the MDT is upgraded from Lustre 1.8 or after the MDT is restored from a file-level backup, the MDT will be missing all the FID-in-dirent data, which will reduce the performance of readdir(3) on the MDT. Additionally, for an MDT upgraded from Lustre 1.8 the linkEA is also unavailable and the 2.x "lctl fid2path" functionality will not be available for those files.

In LFSCK Phase 1.5 we will implement the functionality of verifying and rebuilding FID-in-dirent and linkEA under for the single-MDT case. It will do these additional operations while the MDT is iterating over the objects table for OI Scrub. It will check whether the FID-in-dirent name entry is consistent with the FID in the object LMA or not, repair it if unmatched or rebuild it if the FID-in-dirent is missing. It also verifies that the name entry is correctly referenced by the object linkEA and the object linkEA points back to the valid name entry. The unmatched or redundant object linkEA will be removed, and the missed object linkEA will be added. In the case of Lustre 1.8 inodes with IGIF FIDs after an upgrade, it will store the IGIF FID into the LMA xattr on the inode, then in the FID-in-dirent and linkEA as it would for any 2.x FID.

The LFSCK Phase III project was to handle the FID-in-dirent and linkEA verification. This included both local-MDT references and cross-MDT cases where the directory entry and the object are located on different MDTs. The LFSCK Phase 1.5 implementation of FID-in-dirent and linkEA consistency check/repair contains a significant part of the LFSCK Phase III work.

Currently, the DNE project is underway. To make the LFSCK project less dependent on DNE project, we prefer to split the LFSCK Phase III into two parts: for DNE cases and for non-DNE cases. The part for non-DNE cases will be processed in the LFSCK Phase 1.5, and the other part will be processed after the DNE project completed. Having the LFSCK Phase 1.5 work completed earlier also benefits sites upgrading from Lustre 1.8.

Whamcloud Community JIRA

[LU-1866] LFSCK Phase 1.5 for FID-in-dirent and linkEA consistency