From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Phillips 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 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: Theodore Ts'o , tux3@tux3.org, Dave Chinner , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, OGAWA Hirofumi To: Mike Galbraith Return-path: In-Reply-To: <1430395641.3180.94.camel@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tux3-bounces@phunq.net Sender: "Tux3" List-Id: linux-fsdevel.vger.kernel.org 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