[LU-3268] lod_verify_striping(): bad userland LOV MAGIC: 0xd00bd10b Created: 03/May/13 Updated: 13/Sep/13 Resolved: 13/Jul/13 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.4.0 |
| Fix Version/s: | Lustre 2.4.1, Lustre 2.5.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Li Wei (Inactive) | Assignee: | John Hammond |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | endianness, lod, sparc | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 8103 | ||||||||
| Description |
|
This occurred on a SPARC MDS when an x86 client tried to "lfs setstripe" a new directory:
The number is exactly LOV_USER_MAGIC_V1 swabbed. The client code always send the lov_mds_md_v1 structures in little-endian, and the MDS code do no swabbing for the structures. This is problematic for x86 clients talking with SPARC servers. |
| Comments |
| Comment by Li Wei (Inactive) [ 03/May/13 ] |
|
CC'ed John. |
| Comment by John Hammond [ 06/May/13 ] |
|
Please see http://review.whamcloud.com/6273. |
| Comment by Li Wei (Inactive) [ 07/May/13 ] |
|
It turned out the ll_dir_getstripe path needs fixing as well. On an x86 client talking to a SPARC server, I got:
|
| Comment by John Hammond [ 07/May/13 ] |
|
I think this may only apply to getting lov on the root. In lod_xattr_get() the lmm returned is in the host byte order. I'll submit a patch this evening. |
| Comment by John Hammond [ 08/May/13 ] |
|
Please see http://review.whamcloud.com/6285 for the ll_dir_getstripe()/lod_xattr_get()/fs root LOV EA fix. |
| Comment by John Hammond [ 13/Jul/13 ] |
|
Both patches landed to master. |