On 2019-09-01 21:09, Chris Murphy wrote:
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.
Having the kernel know about it means, among other things, that
switching to actually using the spare when needed is far less likely to
be delayed by an arbitrarily long time. Worst case scenario in
userspace is that the daemon gets paged out, but the executable is on
the volume it's supposed to be fixing and the volume is in a state that
it returns read errors until it gets fixed. In such a case, the volume
will never get fixed without manual intervention. Such a situation is
impossible if it's being handled by the kernel. This could be mitigated
by using mlock, but that brings it's own set of issues.
