[LU-752] e2fsck can fail when encountering empty extended attribute blocks

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Affects Version/s: Lustre 1.8.6
• Labels: e2fsprogs
• Environment: SLES 11SP1
• Severity: 3

Epic

e2fsprogs

• Assignee: Niu Yawei (Inactive)
• Reporter: Ken Hornstein

Description

When using e2fsck to create databases for later usage by lfsck, we ran into a problem where e2fsck would fail; the error was "error: only handle v1/v3 LOV EAs, not 00000001".

After some research, what I found was that as part of pass 1 of e2fsck, e2fsck would call the function e2fsck_lfsck_find_ea(), and that it would occasionally pass down in a blank EA block (I guess it is iterating through all of the EA blocks). For these blank EA blocks the name length (e_name_len) is set to 0. But e2fsck_lfsck_find_ea() calls strncmp() to match the EA name against the values that Lustre uses, and since the length passed into strncmp() is 0, the strncmp always succeeds. But since this isn't a Lustre EA block lfsck_check_lov_ea() fails on it (with the above error).

Attached is a simple change that will check to see if e_name_len is 0 and return from e2fsck_lfsck_find_ea(); this solved our problem. It also occurs to me that for the sake of completeness e_name_len should be checked against the actual lengths of the EA data that Lustre uses; otherwise e2fsck could get confused if someone creates a EA attribute named "lo" or even just "l".

Issue Links

• Trackbacks: Lustre 1.8.x known issues tracker While testing against Lustre b18 branch, we would hit known bugs which were already reported in Lustre Bugzilla https://bugzilla.lustre.org/. In order to move away from relying on Bugzilla, we would create a JIRA