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-15514 Lustre <p>With idle-disconnect code a situation can happen where entire cluster is idle for some time and as all the servers restart, the recovery on OSTs does not start as there are no client connections. The MDTs connections to OSTs are rejected because those are considered to be new connections.</p> <p>We need to either accept new MDTs in similar to how we do when MDT and OST are colocated on the same node or we need to start the recovry time on first such connection and then proceed with the eviction as the timeout expires to allow them to rejoin as the new clients they are.</p> <p>Failing to do this would cause entire cluster delay as the idle-disconnected clients become active again and would need to wait for the recovery to finish first even if the servers restart happened long ago</p> LU-15514

Do not wait for clients to start recovery if there are no clients.

Improvement Minor Open Unresolved WC Triage Oleg Drokin Wed, 2 Feb 2022 22:22:16 +0000 Thu, 3 Feb 2022 03:03:09 +0000 Lustre 2.15.0 0 3 <p>IIRC, the MDT-&gt;OST connections <em>used</em> to use a fixed UUID like "<tt>$fsname-MDT0000_UUID</tt>" or something, so that they could always connect to the OSTs, even during recovery. It's possible that this was changed at one point because of LWP/OUT connections, or something, but this should be investigated. The MDT should not be blocked from connecting during recovery.</p> <p>Whether the MDT connections should trigger the recovery timer is a separate issue. I think they should <b>not</b>, otherwise if the storage cluster is disconnected from the compute nodes because of a brief switch problem then all clients would all be evicted. However, as Oleg noted, if there are no other connections besides the MDT(s), then recovery could finish immediately.</p> <p>ye, MDT connection alone should not trigger start of recovery, except they are the only type of records in last_rcvd.</p> Related Development Rank 1|i02h4f: Rank (Obsolete) 9223372036854775807