Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757527AbcCCSNN (ORCPT ); Thu, 3 Mar 2016 13:13:13 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:29503 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754693AbcCCSNK (ORCPT ); Thu, 3 Mar 2016 13:13:10 -0500 Date: Thu, 3 Mar 2016 10:12:40 -0800 From: "Darrick J. Wong" To: Christoph Hellwig Cc: "Martin K. Petersen" , Linus Torvalds , Jens Axboe , Andrew Morton , 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 Message-ID: <20160303181240.GB8782@birch.djwong.org> References: <20160302040932.16685.62789.stgit@birch.djwong.org> <20160302040947.16685.42926.stgit@birch.djwong.org> <20160302225601.GB21890@birch.djwong.org> <20160303180924.GA4116@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160303180924.GA4116@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1191 Lines: 29 On Thu, Mar 03, 2016 at 10:09:24AM -0800, Christoph Hellwig wrote: > On Thu, Mar 03, 2016 at 01:01:11PM -0500, Martin K. Petersen wrote: > > That's not entirely true. Writing the blocks may cause them to be > > allocated on the storage device (depending on which flags we feed it in > > WRITE SAME). > > > > The filesystems people were wanted the following semantics: > > > > - deallocate, don't care about contents for future reads (discard) > > - deallocate, guarantee zeroes on future reads (zeroout) > > - (re)allocate, guarantee zeroes on future reads (zeroout) > > > > Maybe we just need a better naming scheme... > > In filesystem terms we have two and three: > > - FALLOC_FL_PUNCH_HOLE assures zeroes are returned, but space is > deallocated as much as possible > - FALLOC_FL_ZERO_RANGE assures zeroes are returned, AND blocks are > actually allocated > > Returning stale blocks in a file system is a nasty security risk, so > we don't do that, and so shouldn't storage that offers any kind > of multi tenancy, and if it's just VMs using multiple partitions on it. Any particular reason why we can't just implement those two fallocate flags for block devices? --D