Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751766AbbEFXVz (ORCPT <rfc822;w@1wt.eu>);
	Wed, 6 May 2015 19:21:55 -0400
Received: from imap.thunk.org ([74.207.234.97]:49730 "EHLO imap.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751263AbbEFXVt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 6 May 2015 19:21:49 -0400
Date: Wed, 6 May 2015 19:21:46 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Sage Weil <sweil@redhat.com>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>,
        Zach Brown <zab@redhat.com>, Alexander Viro <viro@zeniv.linux.org.uk>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux API Mailing List <linux-api@vger.kernel.org>
Subject: Re: [PATCH RFC] vfs: add a O_NOMTIME flag
Message-ID: <20150506232146.GB12706@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
	Sage Weil <sweil@redhat.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Zach Brown <zab@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux API Mailing List <linux-api@vger.kernel.org>
References: <1430949612-21356-1-git-send-email-zab@redhat.com>
 <CAHQdGtS0=Gjyq2E2QO+zu_HAzdrHJwxtfZ8MB5q0DjWHMEc7hw@mail.gmail.com>
 <alpine.DEB.2.00.1505061515550.28239@cobra.newdream.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1505061515550.28239@cobra.newdream.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 923
Lines: 22

On Wed, May 06, 2015 at 03:19:13PM -0700, Sage Weil wrote:
> > Just out of curiosity, if you need to modify the application anyway,
> > why wouldn't use of fdatasync() when flushing be able to offer a
> > similar performance boost?
> 
> Although fdatasync(2) doesn't have to update synchronously, it does 
> eventually get written, and that can trigger lots of unwanted IO.

Something that might be worth trying out is using MS_LAZYTIME plus
fdatasync(2).  That should significantly reduce the unwanted IO, while
eventually letting the mtimes get updated, plus allowing updates of
adjacent inodes in the same inode table block update the mtime "for
free".

Regards,

					- Ted
--
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/