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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 5 Aug 2007 09:45:19 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Jakob Oestergaard <jakob@...hought.net>,
	Jeff Garzik <jeff@...zik.org>, miklos@...redi.hu,
	akpm@...ux-foundation.org, neilb@...e.de, dgc@....com,
	tomoki.sekiyama.qu@...achi.com,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	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 Sun, 5 Aug 2007, Ingo Molnar wrote:
> 
> you mean tmpwatch? The trivial change below fixes this. And with that 
> we've come to the end of an extremely short list of atime dependencies.

You wouldn't even need these kinds of games.

What we could do is to make "relatime" updates a bit smarter.

A bit smarter would be:

 - update atime if the old atime is <= than mtime/ctime

   Logic: things like mailers can care about whether some new state has 
   been read or not. This is the current relatime.

 - update atime if the old atime is more than X seconds in the past 
   (defaulting to one day or something)

   Logic: things like tmpwatch and backup software may want to remove 
   stuff that hasn't been touched in a long time, but they sure don't care 
   about "exact" atime.

Now, you could also make the rule be that "X" depends on mtime/ctime, ie 
if a file has been "recently" created or modified, we keep more exact 
track of it and use one hour instead of one day, but if it's some old file 
that hasn't been modified in the last six months, we change X to a week. 
IOW, the "exactness" of atime is relative to how old the inode 
modifications are.

We could obviously do with an additional rule:

 - update atime if the inode is dirty anyway. Logic: there's no downside.

which just says that we'll make it exact if there is no reason not to.

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