From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin K. Petersen" Subject: Re: [PATCH RFC] block: use discard if possible in blkdev_issue_discard() Date: Fri, 14 Feb 2014 12:14:42 -0500 Message-ID: References: <20140214043256.GA5145@thunk.org> Mime-Version: 1.0 Content-Type: text/plain Cc: linux-fsdevel@vger.kernel.org, Jens Axboe To: "Theodore Ts'o" Return-path: Received: from userp1040.oracle.com ([156.151.31.81]:20367 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbaBNROt (ORCPT ); Fri, 14 Feb 2014 12:14:49 -0500 In-Reply-To: <20140214043256.GA5145@thunk.org> (Theodore Ts'o's message of "Thu, 13 Feb 2014 23:32:56 -0500") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: >>>>> "Ted" == Theodore Ts'o writes: Ted, [issue_zeroout_or_write_same] Ted> How do people think I should implement this functionality? I see Ted> three possible choices: I did think about doing this when I originally implemented support for WRITE SAME. However, one caveat is that there are corner cases where devices that -- despite reporting that they return zeroed data after TRIM -- will return non-zeroes. The issue being that TRIM is a hint and there are no hard guarantees. Even if a device reports DRAT/RZAT. So the reason I didn't end up adding a call like yours is that the result is non-deterministic. The call would have to be "please zero this block range but I don't *actually* rely on getting zeroes back". I don't have a problem providing a function that does that as long as the best-effort limitation is made crystal clear. -- Martin K. Petersen Oracle Linux Engineering