mirror of
https://github.com/versity/scoutfs.git
synced 2026-08-16 04:06:39 +00:00
Auke Kok
205cfbdf4a
A node only needs to be fenced once, but scoutfs_fence_start() can be called for the same rid more than once. When a new leader starts it fences the previous leader as it removes it from the quorum (quorum_block_leader), and that same rid can also be a mounted client that then fails to recover within the timeout (client_recovery). The second fence call collides on that name, sysfs returns -EEXIST, and the error is propagated to fence_pending_recov_worker() which treats any error as fatal and shuts the server down. On the next mount a new leader hits the same stale set and the same collision, so the filesystem can never finish recovery. Jun 15 09:22:35 kernel: scoutfs f.000000.r.222222: fencing previous leader f.000000.r.111111 at term 183942 in slot 3 with address x.x.x.x:6000 Jun 15 09:22:36 scoutfs-fenced[9194]: [2026-06-15 09:22:36.588037842] server f.000000.r.222222 fencing rid 1111111111111111 at IP x.x.x.x for quorum_block_leader Jun 15 09:23:09 kernel: scoutfs f.000000.r.222222 error: 30000 ms recovery timeout expired for client rid 1111111111111111, fencing Jun 15 09:23:09 kernel: sysfs: cannot create duplicate filename '/fs/scoutfs/f.000000.r.222222/fence/1111111111111111' Jun 15 09:23:09 kernel: scoutfs f.000000.r.222222 error: fence returned err -17, shutting down server Check the list for the rid and skip the duplicate before creating sysfs. A pending fence can be freed once it is on the list, so a new fi->mutex serializes creation against the freeing path: the duplicate check, sysfs create, and list insert run as a unit, and a fence becomes visible on the list only once it is fully built. scoutfs_fence_free() and scoutfs_fence_stop() take the same mutex around removing a fence and tearing it down, and scoutfs_fence_destroy() drains through fence_stop() rather than walking the list unlocked. Signed-off-by: Auke Kok <auke.kok@versity.com>