[LU-5032] Mount of loopdev in test 54c fails

• Type: Bug
• Resolution: Duplicate
• Priority: Blocker
• Affects Version/s: Lustre 2.6.0
• Environment: Cray clients, 2.6 lustre + LU-3321
• Severity: 3
• Assignee: Bob Glossman (Inactive)
• Reporter: Mark Mansk

Description

Running Sanity on 2.6 + LU-3321 fails test 54c:

mount: wrong fs type, bad option, bad superblock on /tmp/dal/loop54c,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

sanity test_54c: @@@@@@ FAIL: error mounting /tmp/dal/loop54c on /tmp/dal/d54c

dmesg log shows:
Buffer I/O error on device loop3, logical block 0
lost page write due to I/O error on loop3
...
Buffer I/O error on device loop3, logical block 9
lost page write due to I/O error on loop3
EXT2-fs (loop3): error: can't find an ext2 filesystem on dev loop3.
Lustre: DEBUG MARKER: sanity test_54c: @@@@@@ FAIL: error mounting /tmp/dal/loop54c on /tmp/dal/d54c

error coming out of logfile:
mount: wrong fs type, bad option, bad superblock on /tmp/dal/loop54c,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

sanity test_54c: @@@@@@ FAIL: error mounting /tmp/dal/loop54c on /tmp/dal/d54c

This test DOES have http://review.whamcloud.com/9658 in the build.

Addtional patch was LU-3321 that was under test.

Issue Links

• is duplicated by: LU-4351 sanity test_54c: can't find an ext2 filesystem on dev loop3

Comments

[Patrick Farrell (Inactive)]

Thanks, Bob. I'd looked, not sure how I missed LU-4351.

[Bob Glossman (Inactive)]

Known problem. kernel loop devices in SLES11 are incompatible with lustre due to implementation differences between SLES11 and everything else.

[Patrick Farrell (Inactive)]

A few quick clarifications:
The environment for this is the Cray version of SLES11SP3, with master, or 2.5+the LU-3221 patch series, so it seems to have been introduced by that patch series. This issue does not occur on CentOS with the same code.

From my investigation, an EINVAL is coming from the mount process in the kernel. Specifically, the superblock magic being read in doesn't match what's expected for ext2.
This makes me suspect the problem may be in the format step rather than in the mount step.

Unfortunately, as best I can tell, Lustre DK logs (with -1) for this entire test show no errors, so it's been hard to figure out what's going wrong. I'll see about attaching those logs later today.