xfs_healer [LWN.net]

xfs_healer

Posted Jan 25, 2026 11:08 UTC (Sun) by jengelh (subscriber, #33263)
In reply to: xfs_healer by djwong
Parent article: Filesystem medley: EROFS, NTFS, and XFS

How do xfs.ko and xfs_healer work together ensuring that they do not write data simultaneously? For example when a user just so happens to call /bin/rm mere nanoseconds after the kernel has detected corruption in the same file. Or when xfs_healer relocates a piece of data, that a concurrent "open(blah, O_CREAT)" do not write to the same empty block.

to post comments

xfs_healer

Posted Jan 26, 2026 16:47 UTC (Mon) by zhaan (subscriber, #177139) [Link] (1 responses)

Not an expert, but my guess is that the operations would happen sequentially and transactionally. Corruption would be fixed (at block level), then the /bin/rm would execute assuming there weren't other block corruption fixes queued. So you would be injecting a /bin/rm into a process queue.

xfs_healer

Posted Jan 26, 2026 16:57 UTC (Mon) by koverstreet (subscriber, #4296) [Link]

The actual repair code is in kernel, the userspace code is just a driver - it's not reaching around the kernel code and doing its own thing.

So yes, all the normal filesystem locking applies.