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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4957EEA7.3050101@tudelft.nl>
Date:	Sun, 28 Dec 2008 22:24:55 +0100
From:	Éric Piel <E.A.B.Piel@...elft.nl>
To:	Matthew Garrett <mjg59@...f.ucam.org>
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

Matthew Garrett schreef:
> On Sun, Dec 28, 2008 at 08:04:50PM +0100, Éric Piel wrote:
>> Matthew Garrett schreef:
>>> Ensure relatime updates atime at least once per day
>>>     
>>> Allow atime to be updated once per day even with relatime. This lets
>>> utilities like tmpreaper (which delete files based on last access time)
>>> continue working.
>> :
>> Sorry, but I doubt it's a good idea. First, it breaks the simple
>> semantic of relatime (mtime > atime?), mixing it with a rather arbitrary
>> constant. Second, and most important, there are lots of workloads which
>> will be strongly affected by this modification. For instance, running
>> md5sum daily on the filesystem will cause a write for every file.
> 
> Yes. And? I can't think of a single case where something could 
> absolutely depend on the current relatime semantics, so altering them to 
> more usefully match the atime semantics doesn't seem likely to cause any 
> trouble.
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).

> The use case in this case is the significant body of currently installed 
> machines that don't have /tmp on a separate filesystem. In the very 
> common setup of tmpreaper being used, the current relatime semantics 
> will result in undesired data loss. I think the proposed alteration 
> makes the behaviour of relatime massively more useful without any 
> obvious drawbacks.
Yes, it might bring important drawbacks: performance-wise, relatime will
become more like atime, making it much less useful. There is also a
significant number of desktop computers that are turned on once a day,
the boot time may get hindered by those additional writes.

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.

Eric

View attachment "E_A_B_Piel.vcf" of type "text/x-vcard" (368 bytes)