[LU-617] LBUG: (mdt_recovery.c:787:mdt_last_rcvd_update()) ASSERTION(req_is_replay(req)) failed

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.1.0
• Fix Version/s: Lustre 2.2.0, Lustre 2.1.2
• Type: Bug
• Priority: Major
• Reporter: Jian Yu
• Assignee: Niu Yawei (Inactive)
• Resolution: Fixed

Environment

Lustre Tag: v2_1_0_0_RC0
Lustre Build: http://newbuild.whamcloud.com/job/lustre-master/267/
Distro/Arch: RHEL6/x86_64 (kernel version: 2.6.32-131.6.1.el6)

• Severity: 3

Description

While running racer test, the MDS node (fat-amd-3-ib) hit LBUG as follows:

LustreError: 10364:0:(mdt_recovery.c:787:mdt_last_rcvd_update()) ASSERTION(req_is_replay(req)) failed
LustreError: 10364:0:(mdt_recovery.c:787:mdt_last_rcvd_update()) LBUG
Pid: 10364, comm: mdt_11

Call Trace:
[<ffffffffa03ad855>] libcfs_debug_dumpstack+0x55/0x80 [libcfs]
[<ffffffffa03ade95>] lbug_with_loc+0x75/0xe0 [libcfs]
[<ffffffffa03b8d96>] libcfs_assertion_failed+0x66/0x70 [libcfs]
[<ffffffffa09ca90d>] mdt_txn_stop_cb+0xbbd/0xbd0 [mdt]
[<ffffffffa04bf2a2>] dt_txn_hook_stop+0x62/0x80 [obdclass]
[<ffffffffa09598d8>] osd_trans_stop+0x98/0x290 [osd_ldiskfs]
[<ffffffffa0958470>] ? osd_object_write_unlock+0x60/0xd0 [osd_ldiskfs]
[<ffffffffa0922e3a>] mdd_trans_stop+0x1a/0x20 [mdd]
[<ffffffffa0919cbe>] mdd_rename+0x31e/0x21b0 [mdd]
[<ffffffffa03bcbef>] ? cfs_hash_bd_from_key+0x3f/0xc0 [libcfs]
[<ffffffffa0986239>] ? cmm_mode_get+0x109/0x320 [cmm]
[<ffffffffa0986d5a>] cml_rename+0x33a/0xbb0 [cmm]
[<ffffffffa03bd007>] ? cfs_hash_bd_get+0x37/0x90 [libcfs]
[<ffffffffa09864bd>] ? cmm_is_subdir+0x6d/0x2f0 [cmm]
[<ffffffffa04bcef2>] ? lu_object_put+0x92/0x210 [obdclass]
[<ffffffffa09c5196>] mdt_reint_rename+0x1f96/0x23e0 [mdt]
[<ffffffffa03c394b>] ? upcall_cache_get_entry+0x28b/0xa14 [libcfs]
[<ffffffffa09bd74f>] ? mdt_rename_unpack+0x44f/0x6a0 [mdt]
[<ffffffffa091de56>] ? md_ucred+0x26/0x60 [mdd]
[<ffffffffa09bd9df>] mdt_reint_rec+0x3f/0x100 [mdt]
[<ffffffffa05b1984>] ? lustre_msg_get_flags+0x34/0xa0 [ptlrpc]
[<ffffffffa09b5e84>] mdt_reint_internal+0x6d4/0x9f0 [mdt]
[<ffffffffa09ab946>] ? mdt_reint_opcode+0x96/0x160 [mdt]
[<ffffffffa09b61ec>] mdt_reint+0x4c/0x120 [mdt]
[<ffffffffa05b1458>] ? lustre_msg_check_version+0xc8/0xe0 [ptlrpc]
[<ffffffffa09a9bb5>] mdt_handle_common+0x8d5/0x1810 [mdt]
[<ffffffffa05af104>] ? lustre_msg_get_opc+0x94/0x100 [ptlrpc]
[<ffffffffa09aabc5>] mdt_regular_handle+0x15/0x20 [mdt]
[<ffffffffa05bfc7e>] ptlrpc_main+0xb8e/0x1900 [ptlrpc]
[<ffffffffa05bf0f0>] ? ptlrpc_main+0x0/0x1900 [ptlrpc]
[<ffffffff8100c1ca>] child_rip+0xa/0x20
[<ffffffffa05bf0f0>] ? ptlrpc_main+0x0/0x1900 [ptlrpc]
[<ffffffffa05bf0f0>] ? ptlrpc_main+0x0/0x1900 [ptlrpc]
[<ffffffff8100c1c0>] ? child_rip+0x0/0x20

Kernel panic - not syncing: LBUG

Maloo report: https://maloo.whamcloud.com/test_sets/10c0e904-ccc9-11e0-8d02-52540025f9af

Issue Links

• is related to: LU-5283 LU-617 reappears in 2.4.2

Comments

[Peter Jones]

Mike

Oleg thought that this ticket might be one that you might be interested in

Peter

[Jian Yu]

Lustre Tag: v2_1_0_0_RC0
Lustre Build: http://newbuild.whamcloud.com/job/lustre-master/267/
Distro/Arch: RHEL6/x86_64(server), SLES11/x86_64(client)

The same failure occurred: https://maloo.whamcloud.com/test_sets/b4b80e1a-cccf-11e0-8d02-52540025f9af

[Peter Jones]

Niu

Could you please look into this one as your top priority?

Thanks

Peter

[Mikhail Pershin]

Peter, I'd like to track this because I wonder how that can be at all. I'll try to help Nui with this bug

[Niu Yawei (Inactive)]

After looking into the code, I found something interesting:

There are two pairs of last_xid/last_transno in the last_rcvd file, one for close and the other for other reint operations, which means we can have only one reint rpc and one close rpc inflight, the cl_rpc_lock and cl_close_lock on client guarantee this.

However, I found that the setattr with ATTR_FROM_OPEN breaks above rule, it can be parallel with other reint operations (it's serialized by another cl_setattr_lock), however, it uses same last_xid/last_transno slot on server with other reint operations. I think that'll break the resend and recovery badly. (of cousrse, it could trigger this assert as well)

Hi, Mike
Do you know the story of setattr with ATTR_FROM_OPEN? If it's necessary, I think at least we have to add one more last_xid/last_transno slot for it.

[Alexey Lyashkov]

Niu,

I able to replicate that bug without any recovery.

[Niu Yawei (Inactive)]

Hi, Alex

Right, since some setattr can be parallel with other reint operations, there will be race in mdt_txn_stop_cb(). setattr update it's mti_transno with 'lut_last_transno + 1', another reint operation update it's mti_transno with 'lut_last_transno + 2', the reint operation calls mdt_last_rcvd_update() first to set the lcd_last_transno as 'lut_last_transno + 2', then setattr calls mdt_last_rcvd_update() to trigger the assert.

Same race apply to the last_xid, the last_xid on server sometimes will not be the last sent request from client, so resend is broken too.

[Mikhail Pershin]

Niu, note that assert occurs for non-recovery request, that means the logic issue on server - it assign transaction to the rename operation (in logs) but when it is being written the larger transaction number is ondisk. Maybe you are right about parallel setattr, which happens in parallel, transaction increment is done before last_rcvd update, so there can be a race. Can you reproduce bug locally by running racer and check that? It will be enough to use just cl_close_lock for setattr for testing purposes.

[Alexey Lyashkov]

Mike, Nui

if you wait for hour i will upload full debug logs from that issue. it's easy replicate for me with racer.

[Niu Yawei (Inactive)]

Hi, Alex

Did you reproduce it with rhel5 client or rhel6 client? I noticed that ATTR_OPEN is missed in rhel5 kernel, so if the root cause is the the race I mentioned in above comment, it should only can be reproduced on rhel6 client.

[Alexey Lyashkov]

Ni,

I able to reproduce with RHEL6 client/server.
it's reproduced easy for me - just run acc-sm with SLOW=yes + racer (note, that is don't work if you run racer outside acc-sm. why? i don't know).
Log looks to big to be attached into bug ~90Mb, so i put on owned web server
http://umka.sev.net.ua/tmp/lustre.txt.gz
note - that is 800Mb log after decompress.

that is trace for affected rpc.

00000100:00000040:12.0:1314164305.382194:0:9730:0:(lustre_net.h:1649:ptlrpc_rqphase_move()) @@@ move req "New" > "Rpc" req@ffff8802b735c400 x1378001094793755/t0(0) o-1>lustre-MDT0000_UUID@172.18.1.188@o2ib:12/10 lens 464/536 e 0 to 0 dl 0 ref 2 fl New:/ffffffff/ffffffff rc 0/-1
00000100:00000040:12.0:1314164305.382218:0:9730:0:(niobuf.c:681:ptl_send_rpc()) @@@ send flg=0 req@ffff8802b735c400 x1378001094793755/t0(0) o-1->lustre-MDT0000_UUID@172.18.1.188@o2ib:12/10 lens 464/536 e 0 to 0 dl 1314164312 ref 3 fl Rpc:/ffffffff/ffffffff rc 0/-1
00000100:00000040:12.0:1314164305.382239:0:9730:0:(events.c:284:request_in_callback()) incoming req@ffff8802b006d000 x1378001094793755 msgsize 464
00000100:00000200:12.0:1314164305.382246:0:9730:0:(events.c:68:request_out_callback()) @@@ type 4, status 0 req@ffff8802b735c400 x1378001094793755/t0(0) o-1->lustre-MDT0000_UUID@172.18.1.188@o2ib:12/10 lens 464/536 e 0 to 0 dl 1314164312 ref 3 fl Rpc:/ffffffff/ffffffff rc 0/-1
00000100:00000040:12.0:1314164305.382251:0:9730:0:(client.c:2165:__ptlrpc_req_finished()) @@@ refcount now 2 req@ffff8802b735c400 x1378001094793755/t0(0) o-1->lustre-MDT0000_UUID@172.18.1.188@o2ib:12/10 lens 464/536 e 0 to 0 dl 1314164312 ref 3 fl Rpc:/ffffffff/ffffffff rc 0/-1
00000100:00000040:6.0:1314164305.382272:0:9328:0:(lustre_net.h:1649:ptlrpc_rqphase_move()) @@@ move req "New" > "Interpret" req@ffff8802b006d000 x1378001094793755/t0(0) o-1>20852ba5-ddd7-0070-e392-58b36716a7c4@NET_0x9000000000000_UUID:0/0 lens 464/0 e 0 to 0 dl 1314164311 ref 1 fl New:/ffffffff/ffffffff rc 0/-1
00000100:00100000:6.0:1314164305.382290:0:9328:0:(service.c:1705:ptlrpc_server_handle_request()) Handling RPC pname:cluuid+ref:pid:xid:nid:opc mdt_04:20852ba5-ddd7-0070-e392-58b36716a7c4+731:9730:x1378001094793755:12345-0@lo:36
00000004:00000002:6.0:1314164305.382297:0:9328:0:(mdt_handler.c:1611:mdt_reint_opcode()) @@@ reint opt = 2 req@ffff8802b006d000 x1378001094793755/t0(0) o-1->20852ba5-ddd7-0070-e392-58b36716a7c4@NET_0x9000000000000_UUID:0/0 lens 464/0 e 0 to 0 dl 1314164311 ref 1 fl Interpret:/ffffffff/ffffffff rc 0/-1
00000004:00000002:6.0:1314164305.382360:0:9328:0:(mdt_reint.c:283:mdt_md_create()) @@@ Create (17->[0x200000400:0x1a18:0x0]) in [0x200000400:0x1a0a:0x0] req@ffff8802b006d000 x1378001094793755/t0(0) o-1->20852ba5-ddd7-0070-e392-58b36716a7c4@NET_0x9000000000000_UUID:0/0 lens 464/536 e 0 to 0 dl 1314164311 ref 1 fl Interpret:/ffffffff/ffffffff rc 0/-1

and one note - req_is_replay() is

static inline int req_is_replay(struct ptlrpc_request *req)
{
LASSERT(req->rq_reqmsg);
return !!(lustre_msg_get_flags(req->rq_reqmsg) & MSG_REPLAY);
}

so it's need to be client marked that request as replay via
lustre_msg_add_flags(req->rq_reqmsg, MSG_REPLAY);

but it's done just in ptlrpc_retain_replayable_request :/

so i think it's something like memory corruption or forget to clear area before use.

[Alexey Lyashkov]

btw. my backtrace is lots different when reported.
crash> bt
PID: 9328 TASK: ffff8802cf0c9560 CPU: 5 COMMAND: "mdt_04"
#0 [ffff8802cf0cb548] machine_kexec at ffffffff8103697b
#1 [ffff8802cf0cb5a8] crash_kexec at ffffffff810b9128
#2 [ffff8802cf0cb678] panic at ffffffff814c925b
#3 [ffff8802cf0cb6f8] lbug_with_loc at ffffffffa05bbeeb
#4 [ffff8802cf0cb748] libcfs_assertion_failed at ffffffffa05c6d06
#5 [ffff8802cf0cb798] mdt_txn_stop_cb at ffffffffa0b79dad
#6 [ffff8802cf0cb848] dt_txn_hook_stop at ffffffffa06dedb2
#7 [ffff8802cf0cb878] osd_trans_stop at ffffffffa0bec8b8
#8 [ffff8802cf0cb8c8] mdd_trans_stop at ffffffffa0b2998a
#9 [ffff8802cf0cb8d8] mdd_create at ffffffffa0b1e307
#10 [ffff8802cf0cba38] cml_create at ffffffffa0bd22bc
#11 [ffff8802cf0cbaa8] mdt_md_create at ffffffffa0b6f871
#12 [ffff8802cf0cbb48] mdt_reint_create at ffffffffa0b6fba8
#13 [ffff8802cf0cbbc8] mdt_reint_rec at ffffffffa0b6cf1f
#14 [ffff8802cf0cbc18] mdt_reint_internal at ffffffffa0b653e4
#15 [ffff8802cf0cbca8] mdt_reint at ffffffffa0b6574c
#16 [ffff8802cf0cbcf8] mdt_handle_common at ffffffffa0b58b55
#17 [ffff8802cf0cbd78] mdt_regular_handle at ffffffffa0b59b65
#18 [ffff8802cf0cbd88] ptlrpc_main at ffffffffa07ddefe
#19 [ffff8802cf0cbf48] kernel_thread at ffffffff810141ca

and looks mdt server process only create requests in that time.

[Niu Yawei (Inactive)]

Thanks for your help, Alex.

Could you try to apply this patch to your client to see if you can still reproduce it?

[Alexey Lyashkov]

btw. if it's help we can join in Skype chat when get any info from kernel crash dump.

[Alexey Lyashkov]

not sure, that patch can help.
because real request don't have a replay flag, but assert show it's has.
00000100:00100000:6.0:1314164305.382290:0:9328:0:(service.c:1705:ptlrpc_server_handle_request()) Handling RPC pname:cluuid+ref:pid:xid:nid:opc mdt_04:20852ba5-ddd7-0070-e392-58b36716a7c4+731:9730:x1378001094793755:12345-0@lo:36
00000004:00000002:6.0:1314164305.382297:0:9328:0:(mdt_handler.c:1611:mdt_reint_opcode()) @@@ reint opt = 2 req@ffff8802b006d000 x1378001094793755/t0(0) o-1->20852ba5-ddd7-0070-e392-58b36716a7c4@NET_0x9000000000000_UUID:0/0 lens 464/0 e 0 to 0 dl 1314164311 ref 1 fl Interpret:/ffffffff/ffffffff rc 0/-1

so

crash> struct ptlrpc_request ffff8802b006d000
struct ptlrpc_request {
rq_type = 0,
...
rq_nob_received = 0,
rq_reqlen = 464,
rq_reqmsg = 0xffff8802db93a000,
rq_replen = 536,
rq_repmsg = 0xffff8802b58c7908,
rq_transno = 4295025420,
rq_xid = 1378001094793755,
}

crash> struct lustre_msg_v2 0xffff8802db93a000
struct lustre_msg_v2 {
lm_bufcount = 6,
lm_secflvr = 0,
lm_magic = 198183891,
lm_repsize = 536,
lm_cksum = 0,
lm_flags = 3,
lm_padding_2 = 0,
lm_padding_3 = 0,
lm_buflens = 0xffff8802db93a020
}

and

crash> p/x 0xffff8802db93a000+6*sizeof(__u32)+sizeof(struct lustre_msg_v2)
$140 = 0xffff8802db93a038
crash> struct ptlrpc_body 0xffff8802db93a038
struct ptlrpc_body {
pb_handle =

{ cookie = 17939057498874916065 }

,
pb_type = 4711,
pb_version = 131075,
pb_opc = 36,
pb_status = 9730,
pb_last_xid = 0,
pb_last_seen = 0,
pb_last_committed = 0,
pb_transno = 0,
pb_flags = 0,
pb_op_flags = 0,
pb_conn_cnt = 2,
pb_timeout = 6,
pb_service_time = 0,
pb_limit = 0,
pb_slv = 0,
pb_pre_versions =

{0, 0, 0, 0},
pb_padding = {0, 0, 0, 0}

}

so pb_flags == 0, but should be MSG_REPLAY (0x0004) have set.

In that case i think better to verify is assert has correct pointer to ptlrpc request.

[Mikhail Pershin]

Alexey, it expects replay: ASSERTION(req_is_replay(req)), so triggered assertion shows that is NOT replay. Therefore that can be right what Niu found about ATTR_FROM_OPEN, this assertion is not about replay, it happens for normal requests when they change last_transno improperly.

[Alexey Lyashkov]

Ah, i forget about inverse in LASSERT logic.
patch looks fixes a issue and racer work fine for me.

[Mikhail Pershin]

That's very good news, thanks for testing! I am not sure patch is fully correct but at least we know the reason and can think about this better

[Alexey Lyashkov]

Always welcome that patch fixes panic in replay-vbr also.
so I will look into ATTR_FROM_OPEN logic, to verify that solution or find more correct way for it.
Please keep we in loop or add as inspector for final patch.

[Niu Yawei (Inactive)]

Actually, the ATTR_FROM_OPEN logic looks wrong to me.

On the server side, we don't acquire DLM lock for the setattr from open

/* In the raw-setattr case, we lock the child inode.
 * In the write-back case or if being called from open,
 *               the client holds a lock already.
 * We use the ATTR_FROM_OPEN (translated into MRF_SETATTR_LOCKED by
 * mdt_setattr_unpack()) flag to tell these cases apart. */

Howerver, the truth is that the client deosn't hold any lock at all, which means sometimes we could probably set attr to a file without DLM lock!

I think this part of ancient code was introduced to resolve some kind of deadlock/livelock problem, and with code changes, the deadlock/livelock problem doesn't exist anymore, but this part of code was not removed accordingly.

According to the current Lustre implementation, we don't gurantee the atomicity of open(O_TRUNC) (no DLM lock is holding through open+trunc), the open(O_TRUNC) can be regard as an open followed by a immediate truncate, so it looks safe to remove the ATTR_FROM_OPEN and SETATTR portal stuff.

There might be some slight impact on open cache when removing the ATTR_FROM_OPEN stuff, the truncate from open(O_TRUNC) could cause it's open lock being revoked, this looks not so efficient, but I think it's necessary for correctness.

[Oleg Drokin]

Ok, I tracked this change to commit 040033cef24c5aca2967daf2da7a862abcd074cf From Phil on March 2nd, 2003.

It seems two things happened, a new setattr portal was added and at the same time new lock added, as if we can safely send multiple RPCs to different portals back then (we certainly cannot now).

Anyway the patch seems to be totally correct. Can you please get rid of all cl_setattr_lock references and submit a patch like this to gerrit?
Also 1.8 needs the same thing.

[Oleg Drokin]

Ah, on the other stuff you asked about, yes getting rid of attr_from_open and setattr portal seems to be possible.
Clearly the locks depended upon in the days past are no longer exiting.

On the other hand open with O_TRUNC is probably not that a great target for openlock anyway.

[Niu Yawei (Inactive)]

Thank you, Oleg.

patch for master: http://review.whamcloud.com/#change,1295 Will backport it to b1_8 when it's passed review.

[James A Simmons]

I tried this patch and still got errors. I posted the file mds-kern-log to help give insite to what going wrong for runracer.

[Niu Yawei (Inactive)]

Hi, James

The error you got is different from this bug.

Did you use rhel5 client or rhel6 client? Can you reproduce it without the patch? Thanks.

[James A Simmons]

It was with rhl5 clients. Yes I can run it without the patch and open a new bug.

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,el5,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,client,el6,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,server,el5,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,server,el6,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,sles11,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,el6,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,ubuntu1004,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,server,el5,ofa #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,client,el5,ofa #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,el5,ofa #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,server,el5,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,server,el6,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,client,el5,inkernel #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,server,el5,ofa #275
LU-617 temporary fix for the setattr from open

Oleg Drokin : 71fc2a4d9d37c488b64ef882bc83e5096171c703
Files :

• lustre/mdt/mdt_recovery.c

[Peter Jones]

Dropping in priority as workaround landed for 2.1 but keeping open for now as alternative fix to land for 2.2

[Niu Yawei (Inactive)]

fix for 2.2: http://review.whamcloud.com/1654

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,server,el5,ofa #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_handler.c
• lustre/mdt/mdt_lib.c
• lustre/mdt/mdt_reint.c
• lustre/mdc/mdc_request.c
• lustre/include/obd.h
• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_internal.h

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,el6,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_lib.c
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_reint.c
• lustre/include/obd.h
• lustre/mdt/mdt_internal.h
• lustre/mdt/mdt_handler.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,server,el6,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/include/obd.h
• lustre/mdt/mdt_handler.c
• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_lib.c
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_reint.c
• lustre/mdt/mdt_internal.h

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,el5,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_handler.c
• lustre/mdt/mdt_internal.h
• lustre/mdc/mdc_reint.c
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_reint.c
• lustre/include/obd.h
• lustre/mdt/mdt_lib.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,sles11,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_handler.c
• lustre/include/obd.h
• lustre/mdt/mdt_internal.h
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_lib.c
• lustre/mdt/mdt_reint.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,el5,ofa #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_handler.c
• lustre/mdt/mdt_internal.h
• lustre/mdt/mdt_reint.c
• lustre/mdt/mdt_lib.c
• lustre/include/obd.h
• lustre/mdc/mdc_request.c
• lustre/mdc/mdc_reint.c

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,client,ubuntu1004,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_handler.c
• lustre/mdt/mdt_reint.c
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_lib.c
• lustre/include/obd.h
• lustre/mdt/mdt_internal.h

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,server,el5,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_reint.c
• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_lib.c
• lustre/mdt/mdt_internal.h
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_handler.c
• lustre/include/obd.h

[Build Master (Inactive)]

Integrated in lustre-master » x86_64,server,el6,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_internal.h
• lustre/mdt/mdt_reint.c
• lustre/mdt/mdt_handler.c
• lustre/include/obd.h
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_lib.c
• lustre/mdc/mdc_reint.c

[Peter Jones]

Landed for 2.2

[Build Master (Inactive)]

Integrated in lustre-master » i686,client,el6,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_handler.c
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_lib.c
• lustre/mdt/mdt_internal.h
• lustre/mdt/mdt_reint.c
• lustre/include/obd.h
• lustre/mdc/mdc_reint.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,server,el5,ofa #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_reint.c
• lustre/mdt/mdt_handler.c
• lustre/include/obd.h
• lustre/mdt/mdt_lib.c
• lustre/mdc/mdc_request.c
• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_internal.h

[Build Master (Inactive)]

Integrated in lustre-master » i686,server,el5,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_lib.c
• lustre/mdt/mdt_handler.c
• lustre/mdc/mdc_reint.c
• lustre/include/obd.h
• lustre/mdt/mdt_internal.h
• lustre/mdt/mdt_reint.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,client,el5,inkernel #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdt/mdt_lib.c
• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_internal.h
• lustre/mdc/mdc_reint.c
• lustre/mdt/mdt_handler.c
• lustre/include/obd.h
• lustre/mdt/mdt_reint.c

[Build Master (Inactive)]

Integrated in lustre-master » i686,client,el5,ofa #401
LU-617 recovery: setattr from open breaks recovery (Revision 39308b9999b42bf91aff860a71669ca13686c475)

Result = SUCCESS
Oleg Drokin : 39308b9999b42bf91aff860a71669ca13686c475
Files :

• lustre/mdc/mdc_request.c
• lustre/mdt/mdt_lib.c
• lustre/include/obd.h
• lustre/mdt/mdt_handler.c
• lustre/mdt/mdt_reint.c
• lustre/mdt/mdt_internal.h
• lustre/mdc/mdc_reint.c