On Wed, Feb 18 2015 at 11:29am -0500, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > On Wed, 18 Feb 2015, James Bottomley wrote: > > > On Tue, 2015-02-17 at 14:59 -0500, Mikulas Patocka wrote: > > > > > > On Mon, 16 Feb 2015, James Bottomley wrote: > > > > > > > I already said this in the first sentence of the last paragraph of my > > > > email. The point isn't what it does today it's what might happen > > > > tomorrow and the principle of least surprise. One day, someone might > > > > propagate the error. When that happens, they'll be surprised to find > > > > every discard failure reported as -ENOTSUPP and it will cost someone > > > > time and effort to investigate and fix. If you just propagate the error > > > > today, you save all that work in the future. > > > > > > > > James > > > > > > The question is if this case is so important that it justifies dm-io > > > change. > > > > I'm not sure I follow. Are you saying no-one would ever want to > > propagate the error? I think that would be short sighted. > > The SATA device may report success on the trim command and may not trim > any data. I know this is stupid, but the standard allows the device to do > that and the devices are doing that. See this thread > http://www.spinics.net/lists/linux-scsi/msg80297.html > > Consequently, if some filesystem or other application contains the logic > "if trim succeeded, do something", it is broken, because the SSD may > ignore the command and report success. > > > > The SSD may ignore discards and report them as sucesfully completed, so no > > > one should depend on the return code anyway. The error code may be used as > > > a hint that it is futile to send more discards in the future, but relying > > > on the return code is already not correct. > > > > That's not a good way of interpreting the standards. > > It doesn't matter how do you interpret the standard. It does matter how do > SSD vendors interpret it. And they interpret it in such a way that it is > OK to report success and not trim any data. I know it doesn't make much > sense to standardize the flag "Return Zero After Trim" and then specify > that the device (despite having RZAT set) may ignore the trim command and > not return zeroes on the trimmed data. But it's the way it is. Let's please set this thread to one side. I already offered my thoughts in this thread, see: https://www.redhat.com/archives/dm-devel/2015-February/msg00076.html I'm not interested in wiring up the actual error return for dm-mirror's benefit. If/when other dm-io consumers have a need to differentiate between error codes we'll fix dm-io as needed. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
