xfs_healer [LWN.net]

xfs_healer

Posted Jan 23, 2026 18:36 UTC (Fri) by djwong (subscriber, #23506)
Parent article: Filesystem medley: EROFS, NTFS, and XFS

/me notes that xfs_healer is a daemon that will autostart at mount time (if you have systemd) and fix XFS problems in the background if the filesystem is so configured.

For maximum repair abilities, you need to format the filesystem with reverse mapping and parent pointers enabled. This is the default in xfsprogs 6.18; for older versions you can pass “-m rmapbt=1 -n parent=1”. Don't do this if your kernel is older than 6.12; your distributor may not enable online fsck in their kernel configuration.

For self-repair, you also have to enable the xfs_healer_start service (“systemctl enable xfs_healer_start; systemctl start xfs_healer_start”), and set the autofsck property on each filesystem to the value “repair”, either by formatting with “-m autofsck=1” or via “xfs_property <mountpoint or device> set autofsck=repair”. Note that self-repair is still extremely experimental, so don't do this except on a test filesystem that you created by restoring a backup.

Complaints about xfs_healer should be sent to linux-xfs@vger.kernel.org so everyone can see how things are going.

to post comments

xfs_healer

Posted Jan 23, 2026 19:27 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

> systemctl enable xfs_healer_start; systemctl start xfs_healer_start

FYI, `systemctl enable --now xfs_healer_start` combines these.

xfs_healer

Posted Jan 23, 2026 20:16 UTC (Fri) by djwong (subscriber, #23506) [Link]

That's a neat trick that I didn't know about. Thanks for the info!

xfs_healer

Posted Jan 25, 2026 11:08 UTC (Sun) by jengelh (subscriber, #33263) [Link] (2 responses)

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.

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.