linux-ext4 - Re: [PATCH,RFC] ext4: add lazytime mount option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Nov 2014 11:07:10 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Dmitry Monakhov <dmonlist@...il.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH,RFC] ext4: add lazytime mount option

On Wed, Nov 12, 2014 at 04:47:42PM +0300, Dmitry Monakhov wrote:
> Also sync mtime updates is a great pain for AIO submitter
> because AIO submission may be blocked for a seconds (up to 5 second in my case)
> if inode is part of current committing transaction see: do_get_write_access

5 seconds?!?  So you're seeing cases where the jbd2 layer is taking
that long to close a commit?  It might be worth looking at that so we
can understand why that is happening, and to see if there's anything
we might do to improve things on that front.  Even if we can get rid
of most of the mtime updates, there will be other cases where a commit
that takes a long time to complete will cause all sorts of other very
nasty latencies on the entire system.

> Yeah we also has ticket for that :)
> https://jira.sw.ru/browse/PSBM-20411

Is this supposed to be a URL to publically visible web page?

	Host jira.sw.ru not found: 3(NXDOMAIN)

> > +	if (flags & S_VERSION)
> > +		inode_inc_iversion(inode);
	  ....
> Since we want update all in-memory data we also have to explicitly update inode->i_version
> Which was previously updated implicitly here:
> mark_inode_dirty_sync()
> ->__mark_inode_dirty
>   ->ext4_dirty_inode
>     ->ext4_mark_inode_dirty
>       ->ext4_mark_iloc_dirty
>         ->inode_inc_iversion(inode);

It's not necessary to add a anothre call to inode_inc_version() since
we already incremented the i_version if S_VERSION is set, and
S_VERSIOn gets set when it's necessary to handle incrementing
i_Version.

The inode_inc_iversion() in mark4_ext4_iloc_dirty() is probably not
necessary, since we already should be incrementing i_version whenever
ctime and mtime gets updated.  The inode_inc_iversion() there is more
of a "belt and suspenders" safety thing, on the theory that the extra
bump in i_version won't hurt anything.

Cheers,

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