[LU-5268] HSM: importing with copytool can lead to data corruption

• Type: Bug
• Resolution: Won't Fix
• Priority: Minor
• Affects Version/s: Lustre 2.5.0, Lustre 2.5.1
• Labels: HSM
• Severity: 3
• Assignee: WC Triage
• Reporter: Frank Zago (Inactive)

Description

This is a hypothetical bug.

When importing a file with the posix copytool, a hardlink is done at the end to link from the archvie of the file being restored to the new archive file (hash of the new fid). When restoring a complete filesystem, it is very possible that the new fid being allocated already existed on the old filesystem (and thus in the HSM archive). In which case the new archive filename will already exist. At that point the hard link operation in import_one() will fail, which leaves the imported file pointing to the archive of another file, and restoring that file will lead to data corruption.

Solution: link the new archive to a new directory; ie have --hsm-root and --hsm-root-import options. Then, optionally, let the user merge back both directories once the import is done.

Issue Links

• is related to: LU-3565 HSM: Allow specifying minimum FID sequence at format time

Comments

[Frank Zago (Inactive)]

Thanks Thomas. That looks like another good way to solve that problem.

[Thomas LEIBOVICI - CEA (Inactive)]

Following this recovery procedure avoids fid conflicts when reimporting from the archive:

• get the highest fid sequence from the archive:
  lhsmtool_posix --max-sequence <fsname>
• set minimum fid sequence of MDT (see LU-3565).
• reimport entries from the archive

This should be added to the Lustre manual.

[Robert Read]

Yet another reason to not use FIDs as the index of an external archive...