https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3268 Lustre <p>This occurred on a SPARC MDS when an x86 client tried to "lfs setstripe" a new directory:</p> <blockquote> <p>00000004:00000080:30.0:1367562225.034331:2800:27098:0:(lod_lov.c:850:lod_verify_striping()) bad userland LOV MAGIC: 0xd00bd10b</p></blockquote> <p>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.</p> LU-3268

lod_verify_striping(): bad userland LOV MAGIC: 0xd00bd10b

Bug Minor Resolved Fixed John Hammond Li Wei endianness lod sparc Fri, 3 May 2013 07:29:27 +0000 Fri, 13 Sep 2013 01:52:02 +0000 Sat, 13 Jul 2013 11:42:04 +0000 Lustre 2.4.0 Lustre 2.4.1 Lustre 2.5.0 0 3 <p>CC'ed John.</p> <p>Please see <a href="http://review.whamcloud.com/6273" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6273</a>.</p> <p>It turned out the ll_dir_getstripe path needs fixing as well. On an x86 client talking to a SPARC server, I got:</p> <blockquote> <p>LustreError: 23875:0:(dir.c:871:ll_dir_getstripe()) unknown magic: D00BD10B</p></blockquote> <p>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.</p> <p>Please see <a href="http://review.whamcloud.com/6285" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6285</a> for the ll_dir_getstripe()/lod_xattr_get()/fs root LOV EA fix.</p> <p>Both patches landed to master.</p> Related LU-2973 Development Rank 1|hzvq3z: Rank (Obsolete) 8103 Severity