linux-kernel - Re: [PATCH, resend] relatime: Let relatime update atime at least once per day

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, 28 Dec 2008 21:38:52 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Éric Piel <E.A.B.Piel@...elft.nl>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH, resend] relatime: Let relatime update atime at least once per day

On Sun, Dec 28, 2008 at 10:24:55PM +0100, Éric Piel wrote:

> Of course, by construction, there is nothing relying on the current
> relatime semantics. The problem is that whenever you are making relatime
> closer to the atime behaviour, you are also getting closer to the
> original drawbacks of atime (one read generates one write).

If your io is sufficiently limited that one write per file per day is a 
significant problem, then I think there's a more serious underlying 
problem.

> Actually, you are changing relatime from a boolean condition (maximum
> one additional write per write) to a atime with a coarse grain (maximum
> one additional write per day). Today you found a use case that needs a
> precision of one day. Tomorrow, someone else will find a use case that
> needs a precision of one hour. So maybe what is actually needed is a
> third option, a "grainatime" option where you can change the precision
> of the atime.

The answer to "The current two options are suboptimal in almost all 
cases" is very rarely "Add a new option". If boot is touching too many 
files, it should stop touching as many files. If you have crap disks, 
get better disks. If your life is spent tuning fs parameters for 1% 
performance gains, find a better job.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/