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-1253 Lustre <p>Our admins are expanding a 2.1 filesystem with new OSTs. Because of known-and-never-solved issues in 1.8 that made adding OSTs in non-sequential order problematic (break out your hexeditor to fix), the admins are adding the new OSTs one at a time in sequential order.</p> <p>Each addition causes the MGS lock to be revoked from all clients, which causes an MGS reconnect storm. When this happens we see the following:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2012-03-22 15:37:11 Lustre: MGS: Client 1aea7ac4-5b27-3e30-3c57-467cd6aed36f (at 192.168.120.118@o2ib7) reconnecting 2012-03-22 15:37:11 Lustre: Skipped 995 previous similar messages 2012-03-22 15:37:11 LustreError: 12649:0:(obd_class.h:501:obd_set_info_async()) obd_set_info_async: dev 0 no operation 2012-03-22 15:37:11 LustreError: 12649:0:(obd_class.h:501:obd_set_info_async()) Skipped 861 previous similar messages </pre> </div></div> <p>I assume that the call to obd_set_info_async() is the one in target_handle_connect(). </p> <p>Device 0 is the MGS device.</p> Lustre 1.8 and 2.1 clients, servers are lustre 2.1.0-24chaos LU-1253

obd_set_info_async: dev 0 no operation

Bug Minor Resolved Won't Fix Hongchao Zhang Christopher Morrone llnl Thu, 22 Mar 2012 19:13:39 +0000 Sun, 14 Jun 2015 12:43:56 +0000 Sun, 14 Jun 2015 12:43:56 +0000 Lustre 2.1.0 0 3 <p>Hongchao</p> <p>Could you please look into this one?</p> <p>Thanks</p> <p>Peter</p> <p>FYI, console logs from the MDS/MGS node for the whole day are attached to <a href="https://jira.whamcloud.com/browse/LU-1257" title="OST registration snafu" class="issue-link" data-issue-key="LU-1257"><del>LU-1257</del></a> if you want more context.</p> <p>currently, there is only one ldlm_resource for one Lustre system, say, "lustre", "scratch", then if one config log was changed,<br/> all nodes related to this Lustre system will be re-enqueue the config lock to reprocess the config.</p> <p>using the target(MDT or OST) name(say, Lustre-OST0001) or the address of client's super block could fix this issue,<br/> but I am afraid it needs huge work to do.</p> <p>I don't think either of those will be sufficient. In the first (target name), we fail to protect against the admins incorrectly giving two targets the same name. In the second case, if the ost reboots it will no longer have the same super block address.</p> <p>We need something unique that we store ON DISK with the OST before beginning the registration process.</p> <p>I agree that this would be a fairly big project. The original design really didn't consider the possibility of failures during configuration.</p> <p>I have closed our local Jira issue as obsolete. Unless there are objections, I'm happy to close this one out.</p> <p>ok - thanks Mark</p> Development Rank 1|hzw01b: Rank (Obsolete) 10085 Severity