From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751095AbbD2UkK (ORCPT ); Wed, 29 Apr 2015 16:40:10 -0400 Received: from mail.phunq.net ([184.71.0.62]:33802 "EHLO starbase.phunq.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbbD2UkI convert rfc822-to-8bit (ORCPT ); Wed, 29 Apr 2015 16:40:08 -0400 From: Daniel Phillips To: Mike Galbraith Cc: , , , "Theodore Ts'o" , OGAWA Hirofumi Subject: Re: Tux3 Report: How fast can we =?iso-8859-1?Q?fsync=3F?= Date: Wed, 29 Apr 2015 13:40:22 -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: <1430325763.19371.41.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> 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 On Wednesday, April 29, 2015 9:42:43 AM PDT, Mike Galbraith wrote: > > [dbench bakeoff] > > With dbench v4.00, tux3 seems to be king of the max_latency hill, but > btrfs took throughput on my box. With v3.04, tux3 took 1st place at > splashing about in pagecache, but last place at dbench -S. > > Hohum, curiosity satisfied. Hi Mike, Thanks for that. Please keep in mind, that was our B team, it does a full fs sync for every fsync. Maybe a rematch when the shiny new one lands? Also, hardware? It looks like a single 7200 RPM disk, but it would be nice to know. And it seems, not all dbench 4.0 are equal. Mine doesn't have a -B option. That order of magnitude latency difference is striking. It sounds good, but what does it mean? I see a smaller difference here, maybe because of running under KVM. Your results seem to confirm the gap I noticed between Ext4 and XFS on the one hand and Btrfs and Tux3 on the other, with the caveat that the anomalous dbench -S result is probably about running with the older fsync code. Of course, this is just dbench, but maybe something to keep an eye on. Regards, Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Phillips Subject: Re: Tux3 Report: How fast can we =?iso-8859-1?Q?fsync=3F?= Date: Wed, 29 Apr 2015 13:40:22 -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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, tux3@tux3.org, Theodore Ts'o , linux-kernel@vger.kernel.org, OGAWA Hirofumi To: Mike Galbraith Return-path: In-Reply-To: <1430325763.19371.41.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 Wednesday, April 29, 2015 9:42:43 AM PDT, Mike Galbraith wrote: > > [dbench bakeoff] > > With dbench v4.00, tux3 seems to be king of the max_latency hill, but > btrfs took throughput on my box. With v3.04, tux3 took 1st place at > splashing about in pagecache, but last place at dbench -S. > > Hohum, curiosity satisfied. Hi Mike, Thanks for that. Please keep in mind, that was our B team, it does a full fs sync for every fsync. Maybe a rematch when the shiny new one lands? Also, hardware? It looks like a single 7200 RPM disk, but it would be nice to know. And it seems, not all dbench 4.0 are equal. Mine doesn't have a -B option. That order of magnitude latency difference is striking. It sounds good, but what does it mean? I see a smaller difference here, maybe because of running under KVM. Your results seem to confirm the gap I noticed between Ext4 and XFS on the one hand and Btrfs and Tux3 on the other, with the caveat that the anomalous dbench -S result is probably about running with the older fsync code. Of course, this is just dbench, but maybe something to keep an eye on. Regards, Daniel