Re: Spare Volume Features

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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.