Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932942AbcCCXOU (ORCPT ); Thu, 3 Mar 2016 18:14:20 -0500 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:58155 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757906AbcCCXOS (ORCPT ); Thu, 3 Mar 2016 18:14:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AAGQCRxNhWOVEqLHldDhoBAoMPgT+CbYN5n3UGi3eFSIQLhgkCAgEBAoExTQEBAQEBAQcBAQEBQAFAQQEBAwcGg24BAQEDATocKAsIAxgJJQ8FJQMHGgESGYgAB7s4DB4YhTiEB32EEoRgBZcdjVmBaoREiFOOToQLTygug3mDC2OBOwEBAQ Date: Fri, 4 Mar 2016 10:10:50 +1100 From: Dave Chinner 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 Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Message-ID: <20160303231050.GU29057@dastard> References: <20160302040932.16685.62789.stgit@birch.djwong.org> <20160302040947.16685.42926.stgit@birch.djwong.org> <20160302225601.GB21890@birch.djwong.org> <20160303180924.GA4116@infradead.org> <20160303223952.GE24012@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160303223952.GE24012@thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1847 Lines: 46 On Thu, Mar 03, 2016 at 05:39:52PM -0500, Theodore Ts'o wrote: > 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? Well defined, reliable behaviour only, please. If the device can't provide the required hardware offload, then it needs to use the generic, slow implementation of the functionality or report EOPNOTSUPP. > 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. For better or for worse, Ceph is moving away from using filesystems for its back end object store, so the use of such a hack in Ceph has a very limited life. > I told them I had an > out-of-tree patch that had that functionality, and even Ric Wheeler > started getting tempted.... :-) You can tempt all you want, but it does not change the basic fact that it is dangerous and compromises system security. As such, it does not belong in upstream kernels. Especially in this day and age where ensuring the fundamental integrity of our systems is more important than ever. Cheers, Dave. -- Dave Chinner david@fromorbit.com