Greg Freemyer wrote:
Seems to introduce some huge layering violations for Raid 5 / 6 implementations using next generation SSDs to comprise the raid volumes.
.. Possibly so. But having stripe layouts known to the fs layer is a *good* thing, and is pretty much already necessary for decent filesystem performance. It would be better even, if the filesystem would just automatically pick up that information, rather than relying upon mkfs parameters (maybe they already do now ?).
Allowing data to change from the SATA / SAS interface layer and not implementing a signaling mechanism that allows the kernel (or any OS / software tool) to ask which sectors / blocks / erase units have undergone data changes is just bizarre to me.
.. I think that's just blowing smoke. The only sectors/blocks/erase-units which even *might* undergo such changes, are already restricted to those exact units which the kernel itself specificies (by explicitly discarding them). If we care about knowing which ones later on (and we don't, generally), then we (kernel) can maintain a list, just like we do for other such entities. I don't see much of a downside here for any normal users of filesystems. This kind of feature is long overdue. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html