Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752352AbbD3Onp (ORCPT ); Thu, 30 Apr 2015 10:43:45 -0400 Received: from zill.ext.symas.net ([69.43.206.106]:57965 "EHLO zill.ext.symas.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499AbbD3Onm (ORCPT ); Thu, 30 Apr 2015 10:43:42 -0400 X-Greylist: delayed 910 seconds by postgrey-1.27 at vger.kernel.org; Thu, 30 Apr 2015 10:43:42 EDT Subject: Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?) To: Daniel Phillips , Mike Galbraith Cc: Dave Chinner , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, tux3@tux3.org, "Theodore Ts'o" , OGAWA Hirofumi References: <8f886f13-6550-4322-95be-93244ae61045@phunq.net> <1430274071.3363.4.camel@gmail.com> <1906f271-aa23-404b-9776-a4e2bce0c6aa@phunq.net> <1430289213.3693.3.camel@gmail.com> <1430325763.19371.41.camel@gmail.com> <1430334326.7360.25.camel@gmail.com> <20150430002008.GY15810@dastard> <1430395641.3180.94.camel@gmail.com> <1430401693.3180.131.camel@gmail.com> <55423732.2070509@phunq.net> From: Howard Chu Message-ID: <55423C05.1000506@symas.com> Date: Thu, 30 Apr 2015 15:28:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 SeaMonkey/2.37a1 MIME-Version: 1.0 In-Reply-To: <55423732.2070509@phunq.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3233 Lines: 66 Daniel Phillips wrote: > > > On 04/30/2015 06:48 AM, Mike Galbraith wrote: >> On Thu, 2015-04-30 at 05:58 -0700, Daniel Phillips wrote: >>> On Thursday, April 30, 2015 5:07:21 AM PDT, Mike Galbraith wrote: >>>> On Thu, 2015-04-30 at 04:14 -0700, Daniel Phillips wrote: >>>> >>>>> Lovely sounding argument, but it is wrong because Tux3 still beats XFS >>>>> even with seek time factored out of the equation. >>>> >>>> Hm. Do you have big-storage comparison numbers to back that? I'm no >>>> storage guy (waiting for holographic crystal arrays to obsolete all this >>>> crap;), but Dave's big-storage guy words made sense to me. >>> >>> This has nothing to do with big storage. The proposition was that seek >>> time is the reason for Tux3's fsync performance. That claim was easily >>> falsified by removing the seek time. >>> >>> Dave's big storage words are there to draw attention away from the fact >>> that XFS ran the Git tests four times slower than Tux3 and three times >>> slower than Ext4. Whatever the big storage excuse is for that, the fact >>> is, XFS obviously sucks at little storage. >> >> If you allocate spanning the disk from start of life, you're going to >> eat seeks that others don't until later. That seemed rather obvious and >> straight forward. > > It is a logical falacy. It mixes a grain of truth (spreading all over the > disk causes extra seeks) with an obvious falsehood (it is not necessarily > the only possible way to avoid long term fragmentation). You're reading into it what isn't there. Spreading over the disk isn't (just) about avoiding fragmentation - it's about delivering consistent and predictable latency. It is undeniable that if you start by only allocating from the fastest portion of the platter, you are going to see performance slow down over time. If you start by spreading allocations across the entire platter, you make the worst-case and average-case latency equal, which is exactly what a lot of folks are looking for. >> He flat stated that xfs has passable performance on >> single bit of rust, and openly explained why. I see no misdirection, >> only some evidence of bad blood between you two. > > Raising the spectre of theoretical fragmentation issues when we have not > even begun that work is a straw man and intellectually dishonest. You have > to wonder why he does it. It is destructive to our community image and > harmful to progress. It is a fact of life that when you change one aspect of an intimately interconnected system, something else will change as well. You have naive/nonexistent free space management now; when you design something workable there it is going to impact everything else you've already done. It's an easy bet that the impact will be negative, the only question is to what degree. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/