Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933755AbcCPAIm (ORCPT ); Tue, 15 Mar 2016 20:08:42 -0400 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:55515 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751086AbcCPAIk (ORCPT ); Tue, 15 Mar 2016 20:08:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AfCQB9o+hWPFEqLHleKAECgxuBQoZmn3oBAQEBAQEGjAKFVoQLhgcCAgEBAoE8TQEBAQEBAQcBAQEBQUCEQQEBAQMBOhwjBQsIAxgJJQ8FJQMHGhOIHwe/AQEpGYU5hQqEFoRfBZcMQ413gW+Hb4QOgSOOf4JlGYFdKC6JKYE6AQEB Date: Wed, 16 Mar 2016 11:08:23 +1100 From: Dave Chinner To: Linus Torvalds Cc: "Theodore Ts'o" , Ric Wheeler , Andy Lutomirski , One Thousand Gnomes , Gregory Farnum , "Martin K. Petersen" , Christoph Hellwig , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton , Eric Sandeen Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Message-ID: <20160316000823.GJ30721@dastard> References: <20160312003556.GF32214@thunk.org> <20160313233049.GA30721@dastard> <56E69398.7030508@redhat.com> <20160314144603.GO29218@thunk.org> <20160315201431.GG30721@dastard> <20160315223313.GH30721@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 2212 Lines: 55 On Tue, Mar 15, 2016 at 04:14:32PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 4:06 PM, Linus Torvalds > wrote: > > > > And yes, "keep the patch entirely inside google" is obviously one good > > way to limit the interface. But if there are really other groups that > > want to explore this, then that sounds like a pretty horrible model > > too. > > Side note: I really don't see how your argument of "XFS has been able > to do something like this for over a decade, using an even uglier > trick that is hidden and not documented" is at all an argument for > your position. > > You're saying "nobody else should be doing what I've been doing for a > long time", and backing that argument up with "but I don't document > it, and it's completely different because it's done at mkfs/debugfs > time rather than mount-time". You can read it that way, but that is not the message I was trying to get across. The message I was trying to get across is that there are people out there that have been using hacks like what google uses for as long as there have been filesystems around that support unwritten extents. And that they do this even though the benefits of such hacks are marginal and frequently can't be backed up with numbers. We don't support filesystems with unwritten extents disabled. I don't like the fact that there are people who turn them off on XFS filesystems, but we are stuck with it as it is part of the supported on disk format that. The best we can do is to try to prevent unsuspecting users from shooting themselves in the foot with such features, which is what we did by removing the mkfs option back in 2007. Like I said, most people don't know or understand the history.... > But now that people are talking about a filesystem-independent way of > doing the same thing, now it's suddenly poisonous. It's always been poisonous. > Dave, I call BS on your arguments. Or maybe I misunderstood it. But it > does smell very "do what I say, not what I do". We're stuck with a lot of historical functionality in XFS that we can't easily remove or disable. Learn from history, don't repeat it. Cheers, Dave. -- Dave Chinner david@fromorbit.com