Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758580AbcCCWkM (ORCPT ); Thu, 3 Mar 2016 17:40:12 -0500 Received: from imap.thunk.org ([74.207.234.97]:57668 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757139AbcCCWkI (ORCPT ); Thu, 3 Mar 2016 17:40:08 -0500 Date: Thu, 3 Mar 2016 17:39:52 -0500 From: "Theodore Ts'o" To: "Martin K. Petersen" Cc: Christoph Hellwig , Linus Torvalds , "Darrick J. Wong" , 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: <20160303223952.GE24012@thunk.org> Mail-Followup-To: Theodore Ts'o , "Martin K. Petersen" , Christoph Hellwig , Linus Torvalds , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton 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: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1879 Lines: 38 On Thu, Mar 03, 2016 at 01:54:54PM -0500, Martin K. Petersen wrote: > >>>>> "Christoph" == Christoph Hellwig writes: > > Christoph> - FALLOC_FL_PUNCH_HOLE assures zeroes are returned, but > Christoph> space is deallocated as much as possible - > Christoph> FALLOC_FL_ZERO_RANGE assures zeroes are returned, AND blocks > Christoph> are actually allocated > > That works for me. I think it would be great if we could have consistent > interfaces for fs and block. The more commonality the merrier. So a question I have is do we want to add a "discard-as-a-hint" analog for fallocate? In the past we've said no because we don't trust userspace. (We seem to have as a core held belief that application programmers are idiots and are not to be trusted with anything dangerous, even if it would be highly useful in certain use cases.) As a result I'm carrying an out-of-tree patch in our Google kernels so that ext4 will honor BLKDISCARD on files. I can't remember if I floated it on linux-fsdevel, or I didn't bother because I knew it would instantly shot down. I believe it was the former, but I can't be 100% sure. It would be kind of nice, though, if we had some kind of agreement on a consistent, unified interface for all three kinds of "discard-as-a-hint", "zeroout", and "zeroout with deallocation" that worked on block devices and files. Whether it's via fallocate(2) or BLK* ioctls, I'm agnostic. - Ted P.S. Speaking of things that are powerful and too dangerous for application programmers, after the Linux FAST workshop, I was having dinner with the Ceph developers and Ric Wheeler, and we were talking about things they really needed. Turns out they also could use an FALLOC_FL_NO_HIDE_STALE functionality. I told them I had an out-of-tree patch that had that functionality, and even Ric Wheeler started getting tempted.... :-)