September 26, 2023 at 6:25 AM, "Robert Elz" <k...@munnari.oz.au> wrote:
> > Date: Sun, 17 Sep 2023 20:07:39 +0000 > From: "Greg Oster" <os...@netbsd.org> > Message-ID: <20230917200739.b9dadf...@cvs.netbsd.org> > > | Implement hot removal of spares and components. From manu@. > | > | Implement a long desired feature of automatically incorporating > | a used spare into the array after a reconstruct. > > I haven't looked at the changes, but is/was there anything in there > (or one of the other recent changes) which allows for spares to remain > as spares in autoconfigured raid sets after a reboot ? That is, to be > recorded in the filesystem (mostly empty for a spare I assume) that it > is one, and be detected at boot time. No there isn't, but now that we can remove hot spares it could make more sense. Previously hot spares would be "locked in" to the RAID set if they were also auto-configure, with no way to remove them... > Also, pie in the sky request - any ability for a spare to be able to > function as a spare for multiple different raid sets (ones with components > of at least a similar size I'd presume, but as long as the spare is big > enough, it shouldn't matter if some raid sets use smaller components) ? That would be harder to do, especially if hot spares were auto-configured as part of an array... Since we don't currently have the ability to automatically start a reconstruction on a failure it hasn't been the end of the world to not have hot spares available on boot. That is, you simply 'raidctl -a' to add them, and then do the rebuild. The same is true for having a component as a spare for multiple different RAID sets -- you just defer adding it to a set until you need it there, and then rebuild. Perhaps this is something for a 'raid monitoring script/daemon'? (i.e. something that monitors a set of RAIDs for failure, attaches hot spares and rebuilds as needed, etc?) Later... Greg Oster
