NeilBrown <neilb <at> suse.de> writes: > Does your array have a write-intent bitmap configured? > If it does, then "POLICY action=re-add" really should work. Thank you for your insight. You are correct, the array has no write-intent bitmap. > If it doesn't, then maybe you need "POLICY action=spare". OK, I will test this when the notebook is back in the house. Actually, the man page had kind of kept me from trying this, because it mentions the condition "if the device is bare", and I didn't want arbitrary bare disk, partition, or free space to be automatically added, but just to trigger an automatic try with raid members that got pulled and are save to re-sync. (e.g. after the occasional bad block error that gets remapped by the hardrives firmware) [man page: spare works] "as above and additionally: if the device is bare it can become a spare if there is any array that it is a candidate for based on domains and metadata." Also, I wouldn't want a temporarily removed raid member to be added as spare to some other array. Only have them added (re-synced even if no bitmap re-add is possible) to the array they belong according to their superblock. > This isn't the default, because depending on exactly how/why the device > failed, it may not be safe to treat it as a spare. OK, I can imagine detecting the corner cases may require some inteligent error logging. What I am looking for is a safe re-sync configuration option between bitmap-based re-add, and treating a device as arbitrary spare drive. Practically, this could be something like an additional action=re-sync option in between re-add/spare, or having the "re-add" action also do (non-bitmap) full re-syncs, if the device is in a clean state. May recording the fail event count in the remaining superblocks help, as described in http://permalink.gmane.org/gmane.linux.raid/48077 help to detect the clean state? Kind Regards, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
