Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030248AbcCPWYt (ORCPT ); Wed, 16 Mar 2016 18:24:49 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:60485 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966117AbcCPWYm (ORCPT ); Wed, 16 Mar 2016 18:24:42 -0400 Date: Wed, 16 Mar 2016 15:23:43 -0700 From: Chris Mason To: , Linus Torvalds , Dave Chinner , "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 , , Bruce Fields , linux-fsdevel , Jeff Layton Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Message-ID: <20160316222343.GA53649@clm-mbp.thefacebook.com> Mail-Followup-To: Chris Mason , sandeen@redhat.com, Linus Torvalds , Dave Chinner , 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 References: <56E69398.7030508@redhat.com> <20160314144603.GO29218@thunk.org> <20160315201431.GG30721@dastard> <20160315223313.GH30721@dastard> <20160315235216.GI30721@dastard> <56E8A916.8050702@redhat.com> <20160316005117.GA34410@clm-mbp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160316005117.GA34410@clm-mbp.thefacebook.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-16_05:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2393 Lines: 57 On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: > On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: > > On 3/15/16 7:06 PM, Linus Torvalds wrote: > > > On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > > >> > > > >> > It is pretty clear that the onus is on the patch submitter to > > >> > provide justification for inclusion, not for the reviewer/Maintainer > > >> > to have to prove that the solution is unworkable. > > > I agree, but quite frankly, performance is a good justification. > > > > > > So if Ted can give performance numbers, that's justification enough. > > > We've certainly taken changes with less. > > > > I've been away from ext4 for a while, so I'm really not on top of the > > mechanics of the underlying problem at the moment. > > > > But I would say that in addition to numbers showing that ext4 has trouble > > with unwritten extent conversion, we should have an explanation of > > why it can't be solved in a way that doesn't open up these concerns. > > > > XFS certainly has different mechanisms, but is the demonstrated workload > > problematic on XFS (or btrfs) as well? If not, can ext4 adopt any of the > > solutions that make the workload perform better on other filesystems? > > When I've benchmarked this in the past, doing small random buffered writes > into an preallocated extent was dramatically (3x or more) slower on xfs > than doing them into a fully written extent. That was two years ago, > but I can redo it. So I re-ran some benchmarks, with 4K O_DIRECT random ios on nvme (4.5 kernel). This is O_DIRECT without O_SYNC. I don't think xfs will do commits for each IO into the prealloc file? O_SYNC makes it much slower, so hopefully I've got this right. The test runs for 60 seconds, and I used an iodepth of 4: prealloc file: 32,000 iops overwrite: 121,000 iops If I bump the iodepth up to 512: prealloc file: 33,000 iops overwrite: 279,000 iops For streaming writes, XFS converts prealloc to written much better when the IO isn't random. You can start seeing the difference at 16K sequential O_DIRECT writes, but really its not a huge impact. The worst case is 4K: prealloc file: 227MB/s overwrite: 340MB/s I can't think of sequential workloads where this will matter, since they will either end up with bigger IO or the performance impact won't get noticed. -chris