<div dir="ltr">Yes, what Andreas said is correct. This check is really expensive and has never been enabled after the initial development of client I/O code. We should get rid of it.<div><br></div><div>Jinshan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 11:17 PM, Dilger, Andreas <span dir="ltr"><<a href="mailto:andreas.dilger@intel.com" target="_blank">andreas.dilger@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mar 26, 2018, at 23:32, NeilBrown <<a href="mailto:neilb@suse.com">neilb@suse.com</a>> wrote:<br>
><br>
> One failure that I have looked into but haven't posted a patch for yet,<br>
> is that sometimes<br>
> LINVRNT(io->ci_state == CIS_IO_GOING || io->ci_state == CIS_LOCKED);<br>
> in cl_io_read_ahead() fails. When it does, the value is CIS_INIT.<br>
> Tracing through the code, it seem that CIS_INIT is an easy possibility<br>
> since 1e1db2a97be5 ("staging: lustre: clio: Revise read ahead implementation")<br>
> However CIS_IO_GOING and CIS_LOCKED do also happen and I cannot see<br>
> that patht that leads to those - so I didn't feel that I could<br>
> correctly explain the patch.<br>
> I currently have:<br>
><br>
> LINVRNT(io->ci_state == CIS_IO_GOING || io->ci_state == CIS_LOCKED ||<br>
> io->ci_state == CIS_INIT);<br>
> Do you have any idea if that is right?<br>
<br>
It is worthwhile to mention that LINVRNT() doesn't get enabled very often, since this enables some very expensive correctness tests. This means it is entirely possible that this assertion is incorrect since the referenced commit.<br>
<br>
Possibly Jinshan can comment?<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger<br>
Lustre Principal Architect<br>
Intel Corporation<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div>