I'm still mostly convinced the policy questions and management should be dealt with a btrfsd userspace daemon.
Btrfs kernel code itself tolerates quite a lot of read and write errors, where a userspace service could say, yeah forget that we're moving over to the spare. Also, that user space daemon could handle the spare device while its in spare status. I don't really see why btrfs kernel code needs to know about it. It's reserved for Btrfs but isn't used by Btrfs, until a policy is triggered. Plausibly one of the policies isn't even device failure, but the volume is nearly full. Spares should be assignable to multiple Btrfs volumes. And that too can be managed by this hypothetical daemon. -- Chris Murphy
