<div dir="ltr"><div dir="ltr"><div><p class="gmail-isSelectedEnd">We are seeing a serious LNet/ksocklnd issue on an active Lustre MDS/MGS and would appreciate feedback from anyone who has seen similar behaviour.</p><p class="gmail-isSelectedEnd">Environment:</p><ul><li>Lustre version: 2.16.1</li><li>OS: RHEL 9.4</li><li>Kernel: 5.14.0-427.31.1_lustre.el9.x86_64</li><li>Server role: active MDS/MGS</li><li>LNet: TCP</li></ul></div><div>Relevant module information:<br><br>filename:       /lib/modules/5.14.0-427.31.1_lustre.el9.x86_64/extra/lustre/fs/lustre.ko<br>version:        2.16.1<br>rhelversion:    9.4<br>vermagic:       5.14.0-427.31.1_lustre.el9.x86_64 SMP preempt mod_unload modversions</div><div><br></div><div><br></div><div><p class="gmail-isSelectedEnd">Problem summary:</p><p class="gmail-isSelectedEnd">After some Lustre clients reboot, they are sometimes unable to remount the filesystem. On the client side, the mount fails with:</p><pre dir="ltr"><code dir="ltr">mount.lustre: mount PRIMARYMDSIP@tcp:SECONDARYMDS@tcp:/APOLLO at /lustre/metproductionB failed: Input/output error
Is the MGS running?</code></pre><p class="gmail-isSelectedEnd">Also from the client:</p><pre dir="ltr"><code dir="ltr">lctl ping PRIMARYMDSIP@tcp
failed to ping PRIMARYMDSIP@tcp: Input/output error</code></pre><p class="gmail-isSelectedEnd">On the active MDS/MGS, LNet still appears to have the expected local NI up:</p><pre dir="ltr"><code dir="ltr">net:
- net type: tcp
  local NI(s):
  - nid: PRIMARYMDSIP@tcp
    status: up
    interfaces:
      0: enp65s0f0np0
    statistics:
      send_count: 3743678655
      recv_count: 3802449073
      drop_count: 1389
    tunables:
      peer_timeout: 180
      peer_credits: 8
      peer_buffer_credits: 0
      credits: 256
    lnd tunables:
      conns_per_peer: 1
      timeout: 49</code></pre><p>However, when the system is in this bad state, running:</p><p>lnetctl peer show -v<br><br>on the active MDS does not just hang; in our experience it can crash the system.</p><p>The only reliable recovery we have found so far is disruptive:<br><br>Unmount the MGS/MDT targets on the MDS.<br>Remove/reload the LNet/Lustre modules.<br>Remount the MGS/MDT targets.<br><br>After this, clients can mount again.<br><br>Representative MDS kernel messages:<br><br>LNet: Timeout error while writing to CLIENT1IP:1021. Closing socket: rc = -110</p><p>We also see repeated ksocklnd / bulk I/O errors involving specific client NIDs, for example from specific IPs that match 24.04.4 LTS (Noble Numbat) 2.16.1 clients that have the following form:</p><p>LNetError: socklnd_cb.c:1182:ksocknal_process_receive() [0000000011320d5e] Error -71 on read from 12345-CLIENTIP1@tcp ip CLIENTIP1:1021 LNetError: socklnd.c:1580:ksocknal_destroy_conn() Completing partial receive from 12345-CLIENTIP1@tcp[2], ip CLIENTIP1:1021, with error, wanted: 32768, left: 32768, last alive is 0 secs ago LNetError: socklnd.c:1593:ksocknal_destroy_conn() Incomplete receive of lnet header from 12345-CLIENTIP@tcp, ip CLIENTIP:1021, with error, protocol: 3.x. LustreError: events.c:472:server_bulk_callback() event type 3, status -5 LustreError: ldlm_lib.c:3562:target_bulk_io() @@@ network error on bulk WRITE LustreError: ldlm_lib.c:3556:target_bulk_io() @@@ Reconnect on bulk WRITE</p><p>Basic IP reachability to the client NID may still work.</p><p>Clients that do not reboot/work.</p><p>Questions:<br><br>Has anyone seen similar behaviour with Lustre 2.16.1 on RHEL 9.4?<br>Are there known LU tickets involving lnetctl peer show -v hanging or crashing in 2.16.x after client reconnect failures?<br>Are there known ksocklnd fixes after 2.16.1 that would make upgrading to 2.17.x advisable?<br>Is there a safer way to clear bad/stale LNet peer state on the MDS without unloading/reloading LNet and remounting the MGS/MDT?<br>Are there specific diagnostics we should capture before recovery, apart from SysRq blocked-task stacks and a vmcore?</p><p>Best regards,</p><p>GM</p></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>-- </div><div>--</div><div>--</div><div><br></div><div><b>Georgios Magklaras PhD</b></div><div>Chief Engineer</div><div>IT Infrastructure/HPC</div><div>The Norwegian Meteorological Institute</div><div><br></div><div><a href="https://www.met.no/" target="_blank">https://www.met.no/</a></div><div><a href="https://www.steelcyber.com/georgioshome/" target="_blank">https://www.steelcyber.com/georgioshome/</a></div></div></div></div></div>