Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751489AbbD3M6R (ORCPT ); Thu, 30 Apr 2015 08:58:17 -0400 Received: from mail.phunq.net ([184.71.0.62]:44025 "EHLO starbase.phunq.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811AbbD3M6O convert rfc822-to-8bit (ORCPT ); Thu, 30 Apr 2015 08:58:14 -0400 From: Daniel Phillips To: Mike Galbraith Cc: Dave Chinner , , , , "Theodore Ts'o" , OGAWA Hirofumi Subject: Re: xfs: does mkfs.xfs require fancy switches to get decent =?iso-8859-1?Q?performance=3F_(was_Tux3_Report:_How_fast_can_we_fsync=3F)?= Date: Thu, 30 Apr 2015 05:58:29 -0700 User-Agent: Trojita/v0.5-14-g8a2496c; Qt/4.8.6; X11; Linux; Ubuntu 14.04.2 LTS MIME-Version: 1.0 Message-ID: In-Reply-To: <1430395641.3180.94.camel@gmail.com> 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> Organization: tux3.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2139 Lines: 44 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. He also posted nonsense: "XFS, however, will spread the load across many (if not all) of the disks, and so effectively reduce the average seek time by the number of disks doing concurrent IO." False. No matter how big an array of spinning disks you have, seek latency and synchronous write latency stay the same. It is just an attempt to bamboozle you. If instead he had talked about throughput, he would have a point. But he didn't, because he knows that does not help his argument. If fsync sucks on one disk, it will suck just as much on a thousand disks. The talk about filling up from the outside of disk is disingenuous. Dave should know that Ext4 does not do that, it spreads out allocations exactly to give good aging, and it does deliver that - Ext4's aging performance is second to none. What XFS does is just stupid, and instead of admitting that and fixing it, Dave claims it would be great if the disk was an array or an SSD instead of what it actually is. Regards, Daniel -- 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/