[LU-8288] handle error due to file with "no stripe info" rewritten before lfsck is run

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.10.0
• Affects Version/s: Lustre 2.7.0
• Severity: 3
• Assignee: nasf (Inactive)
• Reporter: Nathan Dauchy (Inactive)

Description

This is a followup on the filesystem recovery efforts from LU-8071, in particular the comment:

If you think that the layout LFSCK made wrong decision when re-generated the
"nagtest.toobig.stripes" LOV EA, we need to make new patch to recover it. 

More than just making a wrong decision, lfsck can actually corrupt files when it is run. The case is where the MDT loses stripe information, and then the file is rewritten (or appeneded to?), and then lfsck is run.

In general, it would be good if lfsck can handle "conflicts" more gracefully. I understand that it may not know which object is the right one, but it should not pick them arbitrarily since that can result in a mixed-data file. Additionally, at the time when lfsck is run, it has information about what file an object is associated with, and that could be exposed to the user in the name of the file placed in lost+found.

Issue Links

• is related to: LU-4615 LFSCK 5: OST index verification during the LFSCK_LAYOUT