Spare volumes and hot auto-replacement feature

Spare volumes and hot auto-replacement feature

[Dmitry Katsubo]

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/linux-btrfs@vger.kernel.org/msg48209.html

-- 
With best regards,
Dmitry

Re: Spare volumes and hot auto-replacement feature

[Austin S. Hemmelgarn]

On 2016-05-04 19:18, Dmitry Katsubo wrote:
> 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?
Probably 4.7.  I would not suggest using it in production for at least a 
few cycles though (probably 4.9).
> * 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)
As far as I know, no, it just happens.
> * What happens if spare device is smaller then the (failing) device to be replaced?
I'm pretty sure that it doesn't get replaced.
> * What happens if during the replacement the spare device fails (write error)?
I'm not certain about this one.
> * 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).
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).

Re: Spare volumes and hot auto-replacement feature

[David Sterba]

On Thu, May 05, 2016 at 07:23:11AM -0400, Austin S. Hemmelgarn wrote:
> On 2016-05-04 19:18, Dmitry Katsubo wrote:
> > 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?
> Probably 4.7.  I would not suggest using it in production for at least a 
> few cycles though (probably 4.9).

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).

Re: Spare volumes and hot auto-replacement feature

[Austin S. Hemmelgarn]

On 2016-05-06 05:08, David Sterba wrote:
> On Thu, May 05, 2016 at 07:23:11AM -0400, Austin S. Hemmelgarn wrote:
>> On 2016-05-04 19:18, Dmitry Katsubo wrote:
>>> 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?
>> Probably 4.7.  I would not suggest using it in production for at least a
>> few cycles though (probably 4.9).
>
> 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.

Re: Spare volumes and hot auto-replacement feature

[Anand Jain]

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


On 05/05/2016 07:18 AM, Dmitry Katsubo wrote:
> 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/linux-btrfs@vger.kernel.org/msg48209.html
>