Hi again,
- re: version 1.3 superblock with metadata redundancy
I still think this idea has merit. I've been thinking about playing around and seeing if I could hack something together, mostly as an introduction to kernel coding. Is there a source of good documentation (other than just looking at the .h/.c files) on the interplay between mdadm and the kernel raid code? Or on the superblocks themselves? I'm wondering how much of a faux pas it would be to publish the superblock formats, at least, to a place like wikipedia.
- re: Using the serial numbers of the drives
Putting this info into the UID seems like the simple/easy/no-reason-not-to way to handle it. Ideally, I think it would be a more first-class citizen and have its own dedicated place in the superblock, but the proposed method sounds like low-hanging-fruit.
---
(I'm not sure if the stuff below is already implemented, but I thought I'd mention it)
- New idea: a "sync-as/take-over-for" command
This command would be for use in place of fail/remove/add. Having a command that told a spare drive to begin syncing up to take over for a specific drive in an array (without degrading the array/taking the original drive offline first) would be handy. As a use case, several times I have noticed a single drive in an array starting to display instability. It doesn't necessarily have to be yet falling off the chain, so to speak, to really need replacement/RMA. However, simple fail/remove semantics would require the array to become "degraded" and resynced fresh, leaving a real window of opportunity for bad things to happen. If mdadm could sync the spare as diskX, then take diskX offline (or back to spare?) when synced, that would keep the safety net intact for the array without exposure.
Thanks again!
