[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120514152334.GB29902@fieldses.org>
Date: Mon, 14 May 2012 11:23:34 -0400
From: "J. Bruce Fields" <bfields@...ldses.org>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Theodore Ts'o <tytso@....edu>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] ext4: turn on i_version updates by default
On Mon, May 14, 2012 at 09:02:12AM -0600, Andreas Dilger wrote:
> On 2012-05-14, at 8:06, "J. Bruce Fields" <bfields@...ldses.org> wrote:
> > knfsd needs i_version updates on, as will userspace nfs servers and
> > probably others.
> >
> > The only effects are that inode->i_version is bumped (under the i_lock)
> > in more places, and that ->dirty_inode(I_DIRTY_DATASYNC) may be called
> > more frequently than once per jiffy on write (see file_update_time).
> > However the latter appears to be mostly a no-op in that case.
>
> I thought this can have noticeable performance impact, since ext4_mark_inode_dirty() is quite heavyweight?
There's no reason it should be, should it, if we already just dirtied
the inode a moment ago?
> This is one of the reasons that the i_version update is conditional.
> If someone is exporting a filesystem from userspace the should be able
> to turn this on as a mount option, and knfsd could do it from inside
> the kernel. Why add overhead when it is not needed?
Any user of the change attribute also wants it to function correctly
while they're away.
And if it at all possible I'd rather have it be something that Just
Works rather than something that requires extra configuration.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists