[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <yq1zjg8p38a.fsf@sermon.lab.mkp.net>
Date: Thu, 17 Jul 2014 08:41:09 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: "hch\@infradead.org" <hch@...radead.org>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
"Elliott\, Robert \(Server Storage\)" <Elliott@...com>,
James Bottomley <jbottomley@...allels.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"devel\@linuxdriverproject.org" <devel@...uxdriverproject.org>,
"apw\@canonical.com" <apw@...onical.com>,
"kys\@microsoft.com" <kys@...rosoft.com>,
"stable\@vger.kernel.org" <stable@...r.kernel.org>,
"linux-scsi\@vger.kernel.org" <linux-scsi@...r.kernel.org>,
"ohering\@suse.com" <ohering@...e.com>,
"jasowang\@redhat.com" <jasowang@...hat.com>
Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>>>>> "Christoph" == hch@...radead org <hch@...radead.org> writes:
Christoph> That's mostly because we don't support larger than 512 byte
Christoph> TRIM payloads yet..
I did add support for that a few years back but all hell broke loose and
we had to revert it. There were several drives that failed with more
than 512 bytes of payload despite advertising support for 4K.
It's the same problem that we have now with queued TRIM. There are
several vendors that have implemented it but until we added support in
Linux they had no way of testing it. And as a result their
implementations are buggy. Even with a Linux implementation readily
available it's hard to get them to test since Linux is not a tier 1
platform in the consumer segment. For enterprise drives it's an entirely
different matter, of course...
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists