Hello, Martin. On Wed, Dec 03, 2014 at 09:44:46PM -0500, Martin K. Petersen wrote: > > As defined, the DRAT (Deterministic Read After Trim) and RZAT (Return > Zero After Trim) flags in the ATA Command Set are unreliable in the > sense that they only define what happens if the device successfully > executed the DSM TRIM command. TRIM is only advisory, however, and the > device is free to silently ignore all or parts of the request. > > In practice this renders the DRAT and RZAT flags completely useless and > because the results are unpredictable we decided to disable discard in > MD for 3.18 to avoid the risk of data corruption. > > Hardware vendors in the real world obviously need better guarantees than > what the standards bodies provide. Unfortuntely those guarantees are > encoded in product requirements documents rather than somewhere we can > key off of them programatically. So we are compelled to disabling > discard_zeroes_data for all devices unless we explicitly have data to > support whitelisting them. > > This patch whitelists SSDs from a few of the main vendors. None of the > whitelists are based on written guarantees. They are purely based on > empirical evidence collected from internal and external users that have > tested or qualified these drives in RAID deployments. > > The whitelist is only meant as a starting point and is by no means > comprehensive: > > - All intel SSD models except for 510 > - Micron M5* > - Samsung SSDs > - Seagate SSDs Generally, I'm extremely skeptical about whitelists. It's very difficult to keep them meaningfully up-to-date and often just ends up bit rotting after the initial flurry of updates, especially given how little this particular feature would be visible to most users. If there's something on the horizon which would solve the identification problem and we only have to worry about the current batch of devices, whitelisting can be useful but otherwise I'm not sure this is a good idea. If there currently is no way of properly indicating this feature, let's please disable it unconditionally. If this is absolutely necesary in certain cases (is it?), we can add libata.force flags or sysfs knobs to force enable it for users who care enough about it and knows what they're doing. Thanks. -- tejun -- 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
