[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150513123227.GA3512@quack.suse.cz>
Date: Wed, 13 May 2015 14:32:28 +0200
From: Jan Kara <jack@...e.cz>
To: Sage Weil <sage@...dream.net>
Cc: Theodore Ts'o <tytso@....edu>,
Trond Myklebust <trond.myklebust@...marydata.com>,
Dave Chinner <david@...morbit.com>,
Zach Brown <zab@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux API Mailing List <linux-api@...r.kernel.org>
Subject: Re: [PATCH RFC] vfs: add a O_NOMTIME flag
On Mon 11-05-15 09:24:09, Sage Weil wrote:
> On Mon, 11 May 2015, Theodore Ts'o wrote:
> > On Sun, May 10, 2015 at 07:13:24PM -0400, Trond Myklebust wrote:
> > > That makes it completely non-generic though. By putting this in the
> > > VFS, you are giving applications a loaded gun that is pointed straight
> > > at the application user's head.
> >
> > Let me re-ask the question that I asked last week (and was apparently
> > ignored). Why not trying to use the lazytime feature instead of
> > pointing a head straight at the application's --- and system
> > administrators' --- heads?
>
> Sorry Ted, I thought I responded already.
>
> The goal is to avoid inode writeout entirely when we can, and
> as I understand it lazytime will still force writeout before the inode
> is dropped from the cache. In systems like Ceph in particular, the
> IOs can be spread across lots of files, so simply deferring writeout
> doesn't always help.
Can we get some numbers on this? Before we go on and implement new mount
options, persistent inode flags, open flags, or whatever other crap
(neither of which looks particularly appealing to me) I'd like to know how
big is the performance difference between lazytime + fdatasync and not
updating mtime at all for Ceph...
Honza
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists