[] >> Set something to a sysfs entry to enable the feature (like my RFC patch does to >> have a new sysfs entry for the feature), and readd disk. resync then does 'only >> write mismatch data'. Is this what you asked? > > Yes, that is the sort of thing I was asking for. > When you say "readd disk" I assume you mean to use the --readd option to > mdadm. > The only works when there is a bitmap active on the array, so relatively few > blocks will be resynced so does it really matter which approach is taken? > Always copy, or read-and-test? > > Though maybe you really mean to "--add" the device. In that case it would > probably make sense to add some other option to mdadm to say "enable > read-mostly recovery". I wonder what a good name would be. > --minimize-writes ?? That "minimizing" will be a "magnet" for not-so-experienced users, who will a) enable that option in hope it will run faster, b) will wonder why it is not the default, and c) will ask why it is so much slow... ;) And yes it will be slow for regular rebuild of an array when you replace a disk - because in that case most parts of the new disk will be read AND written, instead of being JUST written to. Maybe --compare-when-write. Note this is useful not only for SSDs, it is very useful in virtual environments too (and WHY use mdadm in virtual environment is a different question). For example, I often test mdadm itself in a virtual machine with 2 virtual disks. Initially these disks are zero-length sparse files, but once a resync/rebuild is run, one of them will have zeros written all over... Thanks, /mjt -- 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
