Re: [PATCH 00/15] btrfs: Hot spare and Auto replace

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

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

On 2015-11-09 05:56, Anand Jain wrote:
> These set of patches provides btrfs hot spare and auto replace support
> for you review and comments.
It's absolutely awesome to see that someone picked up this project, it's 
something that's very useful and helps BTRFS to compete with many 
established storage technologies.  I've got some specific questions below.
>
> First, here below are the simple example steps to configure the same:
>
> Add a spare device:
>      btrfs spare add /dev/sde -f
>
> OR if there is a spare device which is already added before the, just
> run
>
>      btrfs dev scan [/dev/sde]
>
> this will register the spare device to the kernel.
>
>      btrfs fi show
>      Label: none  uuid: 52f170c1-725c-457d-8cfd-d57090460091
> 	Total devices 2 FS bytes used 112.00KiB
> 	devid    1 size 2.00GiB used 417.50MiB path /dev/sdc
> 	devid    2 size 2.00GiB used 417.50MiB path /dev/sdd
>
>      Global spare
> 	device size 3.00GiB path /dev/sde
Would I be correct in assuming that we can have more than one hot-spare 
device at a time?  If so, what method is used to select which one to use 
when one is needed?
>
> Thats it.
>
> Auto replace:
>   Replace happens automatically, that is when there is any write
>   failed or flush failed, the device will be marked as failed, which
>   will stop any further IO attempt to that device. And in the next commit
>   thread cycle the auto replace will pick the spare device (/dev/sde is
>   above example) to replace the failed device. And so the btrfs volume is
>   back to a healthy state.
Is there any possibility we could add a knob to control how many errors 
are needed before the device is marked as failed?  For an enterprise 
environment, immediately marking the device failed is the right thing to 
do, but for home usage it may make more sense to retry the I/O at least 
once before marking the device failed (especially considering that most 
home users don't have ECC memory, and a transient memory error can cause 
an I/O request to fail (I've actually had this happen on my laptop before)).
>
>
> Its btrfs Global spare:
>   as of now only global hot spare is supported, that is hot spare(s)
>   are for all the btrfs FS in the system.
How hard would it be to eventually extend this to per-filesystem hot-spares?
>
> No spare when device failed:
>   It would scan for spare device at the rate of transaction commit
>   and will trigger the auto replace when ever spare device is added.
Does this absolutely have to be polled every commit?  This has serious 
potential to make running on a degraded array have a much bigger impact 
than it does now.  While we obviously want people to notice that their 
array is degraded, killing performance is not the proper way to do that. 
  Couldn't we have a callback when adding a hot-spare that would check 
for failed devices and initiate the replacement automatically for the 
first one found?  Ideally, we should keep the current behavior (assume 
the error was transient, and retry the I/O) when there is no hot-spare 
available.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]