Am Mon, 4 Apr 2016 14:19:23 +0800 schrieb Anand Jain <anand.j...@oracle.com>:
> > Otherwise, I find "hot spare" misleading and it should be renamed. > > I never thought hot spare would be narrowed to such a specifics. [...] > About the naming.. the progs called it 'global spare' (device), > kernel calls is 'spare'. Sorry this email thread called it > hot spare. I should have paid little more attention here to maintain > consistency. > > Thanks for the note. I think that's okay. Maybe man pages / doc should put a note that there's no copy-back and that the spare takes a permanent replacement role. Side note: When I started managing hardware RAIDs a few years back, "hot spare" wasn't very clear to me, and I didn't understand why there is a copy-back operation (given that "useless" +1x IO). But in the long term it keeps drive arrangement at expectations - which is good. RAID board manufacturers seem to differentiate between those two replacement strategies - and "hot spare" always involved copy-back for me: The spare drive automatically returns to its hot spare role. I learned to like this strategy. It has some advantages. You could instead assign a replacement drive - then drives will become rearranged in the array. This is usually done by just onlining one spare disk, start a replace action, then offline the old drive and pull it from the array. It's not "hot" in that sense. It's been unconfigured good. Not sure if this could be automated - I did it this way only when the array hasn't been equipped with a spare inside the enclosure but the drive being still in its original box. Other than that, I always used the hot spare method. That's why I stumbled across... -- Regards, Kai Replies to list-only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
