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-3456 Lustre <p>I see this message at startup time on the MDS. If it's safe to ignore, it should be removed. If it's important, it should be refactored to be understandable by an admin (I don't even know what it means, and it's a console message).</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2013-06-11 12:53:52 LustreError: 11-0: lc2-OST0007-osc-MDT0000: Communicating with 10.1.1.48@o2ib9, operation ost_connect failed with -19. </pre> </div></div> LU-3456

Remove or refactor "ost_connect failed" message

Bug Minor Resolved Fixed Zhenyu Xu Prakash Surya shh Tue, 11 Jun 2013 20:35:31 +0000 Thu, 26 Feb 2015 21:56:44 +0000 Thu, 26 Feb 2015 21:56:44 +0000 Lustre 2.4.0 Lustre 2.7.0 0 7 <p>Bobijam</p> <p>Could you please help with this one?</p> <p>Thanks</p> <p>Peter</p> <p>it's from ptlrpc_check_status(), indicating when MDS is start up, it tries to connect OST while at the time OST device is not available.</p> <p>The comment in ptlrpc_console_allow() reveals that the error happens in the initial connection is not suppressed, while reconnect request error messages will be suppressed.</p> <p>Bobi</p> <p>So could you propose an alternative wording for the message that would be more intuitive?</p> <p>Thanks</p> <p>Peter</p> <p>This message indicates that MDS tries to connect OST0007 while the OSS hasn't set up OST0007 yet or the OST0007 is failed for the time being (-19 == -ENODEV)</p> <p>So then, that sounds like "normal" operation to me. I don't think it warrants a console message. It's probably an artifact of how I sometimes power cycle all server nodes in a test filesystem. If the MDS comes up before the OSS nodes, then this message will appear?</p> <p>Prakash, you are correct that this can happen if the MDS is started before the OSS. The message is printed to the console to alert the sysadmin in case the target OST is not starting up properly, but I agree it is a distraction if it is printed due to some transient condition.</p> <p>That said, when Brian submitted the patch to update this console message he left in the printing of errors during the initial connection attempt. I think it would make sense to avoid printing this error if there are just a small number of failed initial connection attempts, but still print something if the connection is failing for a long time. It seems reasonable to only print out such messages when there are persistent problems on the connection.</p> <p>I've pushed an RFC patch <a href="http://review.whamcloud.com/10057" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10057</a> but I haven't tested it at all. In particular, I'm not sure if the same request is used repeatedly for the initial connection (which means rq_nr_resends is properly incremented) or if a new request is used each time (which means my attempt at squashing the initial connect messages will fail). Bobijam, could you please take a look at this?</p> <blockquote> <p>I think it would make sense to avoid printing this error if there are just a small number of failed initial connection attempts, but still print something if the connection is failing for a long time. It seems reasonable to only print out such messages when there are persistent problems on the connection.</p></blockquote> <p>Yes, I think I agree. Since we don't have any better infrastructure for reporting things like this, I'm more OK with the message if we just try and suppressed the "noise".</p> <p>I still don't think the console is the "right" place for it, but that's all we have at the moment. It would be really cool to be able to, instead, post some sort of event that a another process (e.g. userspace daemon) could consume and then decide what to do (e.g. ignore, ping monitoring software, send email, etc). But that's a whole 'nother can of worms.</p> <p>I think having some sort of timer (or number of resends) to suppress the message would go a long way in this particular case.</p> <p>Andreas,</p> <p>It does not use the same request for initial connection, it changes the import status to DISCONN then CONNECTING and constructs new request (since it could possible select different connection for the import) for connection.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/10057/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10057/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-3456" title="Remove or refactor &quot;ost_connect failed&quot; message" class="issue-link" data-issue-key="LU-3456"><del>LU-3456</del></a> ptlrpc: quiet errors on initial connection<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: d1cf226d04884a102e17a7d4109764c24572983f</p> <p>Patch landed to 2.7.0 to improve console message and quiet it down considerably.</p> Development Rank 1|hzvt2n: Rank (Obsolete) 8640 Severity