Whamcloud Community JIRA

Whamcloud Community JIRA https://jira.whamcloud.com This file is an XML representation of an issue en-us

9.4.14

940014

05-12-2023

[LU-186] recovery-mds-scale (FLAVOR=OSS): (filter.c:151:filter_finish_transno()) LBUG https://jira.whamcloud.com/browse/LU-186 Lustre <p>the last_rcvd could be equal to lcd->lcd_last_transno in some special cases, then change "<=" into<br/> "<", and add some more debug info atm.</p> LU-186

recovery-mds-scale (FLAVOR=OSS): (filter.c:151:filter_finish_transno()) LBUG

Bug Minor Resolved Fixed Hongchao Zhang Hongchao Zhang Fri, 1 Apr 2011 19:30:31 +0000 Wed, 6 Apr 2011 21:31:30 +0000 Wed, 6 Apr 2011 21:31:30 +0000 Lustre 2.1.0 Lustre 2.1.0 0 0 <p>Are you sure that bug exists in master? There is no '<=' check in filter_finish_transno() but assertion LASSERT(last_rcvd >= le64_to_cpu(lcd->lcd_last_transno)); which is correct.</p> <p>yes, there is no such issue in master.<br/> as for the cause of the bug, i am a little confused about the comment#5 of 20394 in bugzilla,</p> <p>...<br/> if (last_rcvd <= le64_to_cpu(lcd->lcd_last_transno)) </p> { spin_unlock(&filter->fo_translock); LBUG(); } <p>last_rcvd likely equals to lcd->lcd_last_transno because the transaction of setattr might already<br/> been committed, but the server doesn't have a chance to send the reply to the client side, which<br/> then causes the request being handled immediately. For this case, at lease assertion for last_rcvd<br/> == lcd->lcd_last_transno might be (wrongly) hit.<br/> ...</p> <p>this issue should be caused by resent replay request, which cause the transno in the replay<br/> request equals to the transno in lcd->lcd_last_transno, is that correct?</p> Bugzilla ID 20394.0 Development Rank 1|hzw03r: Rank (Obsolete) 10096 Severity