From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin K. Petersen" Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Date: Thu, 03 Mar 2016 13:14:12 -0500 Message-ID: References: <20160302040932.16685.62789.stgit@birch.djwong.org> <20160302040947.16685.42926.stgit@birch.djwong.org> <20160302225601.GB21890@birch.djwong.org> <20160303170205.GD24012@thunk.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Linus Torvalds's message of "Thu, 3 Mar 2016 09:55:38 -0800") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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-ZPxbGqLxI0U@public.gmane.org, Bruce Fields , linux-fsdevel , Jeff Layton List-Id: linux-api@vger.kernel.org >>>>> "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