|
Client log from failed lfs setstripe.
|
|
I am not able to set striping using xattrs any longer either. Interestingly, there are no error codes returned by the xattr striping path, the setting are just ignored.
|
|
Chris, do you know what version was the last one that worked? The one patch I can think of off the top of my head is the lmm_layout_gen change (commit f90abfdc9), but it was landed way back in 2.1.53, so I'd think you have used PPC since then.
|
|
Bobijam
Could you please look into this one?
Thanks
Peter
|
|
Andreas, unfortunately no, I can't remember specifically in which version last I last successfully used striping. I suspect it worked in either 2.1.56 or 2.1.57, because I was testing striping through xattrs, which led me to submit the LU-2485 bug. But I could be wrong.
|
|
Can I have the verbose MDS log of the operation please?
|
|
Attached files mds_lustre_log.txt.bz2 and client_lustre_log.txt.bz2. This was full debugging while running the following:
The client's nid is 172.20.12.1@o2ib500.
The MDS's nid is 172.20.5.1@o2ib500.
|
|
From mds log, it reports that the client pattern data is erroneous (stripe pattern: 0x0)
00000100:00000001:12.0:1357842862.414573:0:13308:0:(pack_generic.c:2160:lustre_swab_lov_user_md_v1()) Process entered
00000100:00000080:12.0:1357842862.414574:0:13308:0:(pack_generic.c:2161:lustre_swab_lov_user_md_v1()) swabbing lov_user_md v1
00000100:00000001:12.0:1357842862.414575:0:13308:0:(pack_generic.c:2146:lustre_swab_lov_user_md_common()) Process entered
00000100:00001000:12.0:1357842862.414575:0:13308:0:(pack_generic.c:2133:print_lum()) lov_user_md ffffc900a2aa11f8:
00000100:00001000:12.0:1357842862.414576:0:13308:0:(pack_generic.c:2134:print_lum()) lmm_magic: 0xbd10bd0
00000100:00001000:12.0:1357842862.414576:0:13308:0:(pack_generic.c:2135:print_lum()) lmm_pattern: 0x0
00000100:00001000:12.0:1357842862.414577:0:13308:0:(pack_generic.c:2136:print_lum()) lmm_object_id: 0
00000100:00001000:12.0:1357842862.414577:0:13308:0:(pack_generic.c:2137:print_lum()) lmm_object_gr: 0
00000100:00001000:12.0:1357842862.414577:0:13308:0:(pack_generic.c:2138:print_lum()) lmm_stripe_size: 0x0
00000100:00001000:12.0:1357842862.414578:0:13308:0:(pack_generic.c:2139:print_lum()) lmm_stripe_count: 0x2
00000100:00001000:12.0:1357842862.414578:0:13308:0:(pack_generic.c:2141:print_lum()) lmm_stripe_offset/lmm_layout_gen: 0xffff
00000100:00000001:12.0:1357842862.414578:0:13308:0:(pack_generic.c:2155:lustre_swab_lov_user_md_common()) Process leaving
00000100:00000001:12.0:1357842862.414579:0:13308:0:(pack_generic.c:2163:lustre_swab_lov_user_md_v1()) Process leaving
00020000:00000001:12.0:1357842862.414579:0:13308:0:(lod_qos.c:1213:lod_use_defined_striping()) Process entered
00000004:00000001:12.0:1357842862.414580:0:13308:0:(lod_lov.c:726:lod_verify_striping()) Process entered
00000004:00000080:12.0:1357842862.414581:0:13308:0:(lod_lov.c:742:lod_verify_striping()) bad userland stripe pattern: 0x0
00000004:00000001:12.0:1357842862.414581:0:13308:0:(lod_lov.c:743:lod_verify_striping()) Process leaving (rc=18446744073709551594 : -22 : ffffffffffffffea)
|
|
patch tracking at http://review.whamcloud.com/4996
|
|
lfs setstripe appears to work again with patch 4996 applied. Thanks!
|
|
It looks like the fix still leaves something not-quite-right with the swabbing because I am seeing this:
The command succeeds though.
|
|
What does further "$ lfs getstripe nine" come out? Also success w/o error message in dmesg?
|
|
Since I don't have ppc node, would you mind collecting -1 logs of MDS/Client w/ patch 4996 applied?
|
|
lfs getstripe works without an error.
I just did the following:
The client log will be attached as "seqio1_log2.txt.bz2", and mds log will be in "grove-mds1_log2.txt.bz2".
|
|
In seqio1_log2.txt.bz2, I saw that in lov_getstripe(), lov_packmd() was called twice
While in our 2.4 source code, lov_getstripe() only calls it once, is it possible that there is discrepancy between our source codes?
|
|
I believe that log was taken when running 2.3.58-5chaos. Looking at lov_getstripe, lov_packmd is called once, and obd_packmd is called once (which appears to then call lov_packmd).
Here's the source level information, with inlined git blame info for each line as well:
Looking at the git blame info, both calls have been in place for a long time. So this doesn't appear to be a discrepancy issue between our trees.. I'm curious why obd_free_diskmd (i.e. obd_packmd) isn't called in your local test case.
|
|
sorry, your are right, obi_free_diskmd() called lov_packmd(), and the root cause is it
rc = lov_pack(exp, &lmmk, lsm); ---> lmmk LE endianness
...
if ((cpu_to_le32(LOV_MAGIC) != LOV_MAGIC) &&
((lmmk->lmm_magic == cpu_to_le32(LOV_MAGIC_V1)) ||
(lmmk->lmm_magic == cpu_to_le32(LOV_MAGIC_V3)))) {
lustre_swab_lov_mds_md(lmmk);
lustre_swab_lov_user_md_objects(
(struct lov_user_ost_data*)lmmk->lmm_objects,
lmmk->lmm_stripe_count);
} ---> lmmk host endianness (BE)
...
obd_free_diskmd(exp, &lmmk); ---> but obd_free_diskmd() presumes that lmmk is LE, so that lov_packmd() errored out w/o free the memory.
|
|
the 2nd issue patch tracking at http://review.whamcloud.com/5145
|
|
Second patch landed for 2.4.
|
Generated at Sat Feb 10 01:26:29 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.
LU-2590_log.txt.bz2