linux-kernel - Re: [PATCH 00/23] per device dirty throttling -v8

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]

Message-ID: <20070811231428.GA16355@rainbow>
Date:	Sat, 11 Aug 2007 17:14:28 -0600
From:	Valerie Henson <val@....edu>
To:	Martin Bligh <mbligh@...igh.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	J??rn Engel <joern@...fs.org>, Ingo Molnar <mingo@...e.hu>,
	Jeff Garzik <jeff@...zik.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	miklos@...redi.hu, neilb@...e.de, dgc@....com,
	tomoki.sekiyama.qu@...achi.com, nikita@...sterfs.com,
	trond.myklebust@....uio.no, yingchao.zhou@...il.com,
	richard@....demon.co.uk, david@...g.hm
Subject: Re: [PATCH 00/23] per device dirty throttling -v8

On Wed, Aug 08, 2007 at 05:54:57PM -0700, Martin Bligh wrote:
> Andrew Morton wrote:
> >On Wed, 08 Aug 2007 14:10:15 -0700
> >"Martin J. Bligh" <mbligh@...igh.org> wrote:
> >
> >>Why isn't this easily fixable by just adding an additional dirty
> >>flag that says atime has changed? Then we only cause a write
> >>when we remove the inode from the inode cache, if only atime
> >>is updated.
> >
> >I think that could be made to work, and it would fix the performance
> >issue.
> >
> >It is a behaviour change.  At present ext3 (for example) commits everything
> >every five seconds.  After a change like this, a crash+recovery could cause
> >a file's atime to go backwards by an arbitrarily large time interval - it
> >could easily be months.
> 
> A second pdflush / workqueue at a slower rate would alleviate that.

This becomes delayed atime writes.  I'm not sure that it's better to
batch up the writes and do them all in one big seeky go, or to trickle
them out as they are done.  Best of all is not to do them at all.

Note when talking about saving up atime updates to write out that the
final write is going to be sloooooow.  Inodes are typically 128 bytes,
and you may have to do a seek between every one.  Currents disks can
do on the order of 100 seeks a second.  So do a find on 1000 files and
you've just created 10 seconds of I/O hanging out in memory.

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