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/sdeFirst 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.
AFAICT, you are correct. I hadn't yet gotten a chance to look at the actual code, so I hadn't seen this yet.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.
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).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).
smime.p7s
Description: S/MIME Cryptographic Signature
