From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: Linus Torvalds Cc: "Theodore Ts'o" , "Darrick J. Wong" , Jens Axboe , Christoph Hellwig , Andrew Morton , "Martin K. Petersen" , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks From: "Martin K. Petersen" References: <20160302040932.16685.62789.stgit@birch.djwong.org> <20160302040947.16685.42926.stgit@birch.djwong.org> <20160302225601.GB21890@birch.djwong.org> <20160303170205.GD24012@thunk.org> Date: Thu, 03 Mar 2016 13:14:12 -0500 In-Reply-To: (Linus Torvalds's message of "Thu, 3 Mar 2016 09:55:38 -0800") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: >>>>> "Linus" == Linus Torvalds writes: Linus> On Thu, Mar 3, 2016 at 9:02 AM, Theodore Ts'o wrote: >> >> There is a massive bug in the SATA specs about trim, which is that it >> is considered advisory. So the storage device can throw it away >> whenever it feels like it. (In practice, when it's too busy doing >> other things). Linus> Ugh. SCSI UNMAP provides similar semantics :( Linus> But that essentially says that we shouldn't expose this interface Linus> at all (unless we trust our white-lists - I'm sure they are Linus> getting better, but if nobody has ever really _relied_ on the Linus> zeroing behavior of trim, then I guess there could be tons of Linus> bugs lurking). We started out with the blacklist approach and it blew up. So now we're down to a whitelist of drives that have been sanctioned by their manufacturers to do the right thing. Occasionally a new SSD model messes things up but we haven't updated it since last summer. The drive vendors are much better at testing using Linux than they used to be. -- Martin K. Petersen Oracle Linux Engineering