On 2015-11-09 16:29, Duncan wrote:
> Austin S Hemmelgarn posted on Mon, 09 Nov 2015 09:09:07 -0500 as
> excerpted:
>
>>>    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
>
> First of all, thanks from me too, AJ, for this very nice new feature. =:^)
>
>> 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?
>
> In the later patches overview section, patches 10,11,12,13/15 paragraph,
> AJ mentions a helper function to pick/release a spare device from/to the
> spare devices pool.  That would appear to be patch 13, provide framework
> to get and put a spare device.
>
> Which means yes, multiple hot-spares are (at least planned to be)
> allowed. =:^)
Ah, you're right, somehow I missed that bit.
>
> While I'm not a coder and could very well be misinterpreting this,
> however, reading the btrfs_get_spare_device function in patch 13, there's
> a comment that goes like this:
>
>>> /* as of now there is only one device in the spare fs_devices */
>
> I don't read C well enough to know whether that's a comment on the
> internal progress in the function (tho I don't see any obvious hints to
> indicate that), or whether it can be taken at face value, that right now
> there's only provision for one in the "pool" (seems the more obvious
> interpretation).
>
> So unless my lack of C skills is deceiving me, while a pool is intended,
> current patch implementation status simply assumes a spare pool of one,
> and the first spare found is picked. The put function in the same patch
> doesn't appear to have a limit on the number of spares that can be added,
> so assuming the current pool implementation allows it, more than one
> spare can be added to the pool, but as I said, the get function appears
> to assume just one in the pool, so picks the first spare it finds.
AFAICT, you are correct.  I hadn't yet gotten a chance to look at the 
actual code, so I hadn't seen this yet.
>
> At least at the non-enterprise level, size-similar picking logic would
> seem to be pretty useful if not feature critical, then, and given that
> it /should/ be reasonably simple to implement, I'd hope that doing so
> becomes a priority, tho certainly an initial first-pick base
> implementation to which size-similar logic can be added later, is fine as
> well.  I'd just hope that "later" is within a couple kernel cycles, not a
> couple kernel major version cycles (~4 years each with bumps at .20).
>
Hopefully, per-filesystem hot-spares will be a high priority too, as 
that type of usage is pretty much required for many enterprise type 
uses, although that doesn't need to be the same code doing it (in fact, 
I could see having per-fs spares and global spares both available 
potentially being very useful).