Spare volumes and hot auto-replacement feature

Dear btrfs community,

I am interested in spare volumes and hot auto-replacement feature [1]. I have a couple of questions:

* Which kernel version this feature will be included?
* The description says that replacement happens automatically when there is any write failed or flush failed. Is it possible to control the ratio / number of such failures? (e.g. in case it was one-time accidental failure)
* What happens if spare device is smaller then the (failing) device to be replaced?
* What happens if during the replacement the spare device fails (write error)?
* Is it possible for root to be notified in case if drive replacement (successful or unsuccessful) took place? Actually this question is actual for me for overall write/flush failures on btrfs volume (btrfs monitor).

Many thanks!

[1] https://www.mail-archive.com/[email protected]/msg48209.html

With best regards,
Dmitry

Probably 4.7. I would not suggest using it in production for at least a few cycles though (probably 4.9).

As far as I know, no, it just happens.

I'm pretty sure that it doesn't get replaced.

I'm not certain about this one.

There isn't any built-in monitoring in BTRFS that I know of, there are a couple of options though for monitoring. The simplest and probably most reliable is to write a script to poll for changes in the error counts. You can also check the filesystem mount options (without the hot-spare functionality, if there's an error, the filesystem will (usually) get remounted read-only, and this also works for most other filesystems too).

I wonder what are the grounds of the prediction, 4.7 is pretty much done regarding new features. And given the number of other features that are considered for merge I don't know an ETA. I haven't looked at the patches yet (but don't know about others).

I was under the impression that you had pulled them into your for-next branch, and forgot that that would mean probably mean 4.8 at the earliest, although looking at your tree now, I notice that the only patch from the series there is the first one which fixes a lockdep warning, and looking again at the ML is the only one you said you added.

So, taken altogether, the prediction was largely predicated on me being significantly absent-minded.

Most of it (like policy tuning/configuring/notification) is through sysfs interface, However to implement this, we need the existing sysfs volume patches to be integrated.
We need to think about the implementation of per-FSID spare which I hope will solve the problem incompatible spare disk.
As of now if auto replace fails, spare device is out of the kernel device list. If user wants to give a 2nd try then, they should run btrfs dev scan again. And the degraded vol will continue to look for the spare device.

Thanks for the feedback.

Anand