linux-kernel - Re: [PATCH 2/2] Make relatime default

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:	Mon, 30 Mar 2009 16:42:13 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Matthew Garrett <mjg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
	Jan Kara <jack@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <npiggin@...e.de>,
	Jens Axboe <jens.axboe@...cle.com>,
	David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [PATCH 2/2] Make relatime default

On Thu, Mar 26, 2009 at 06:48:38PM +0000, Alan Cox wrote:
> On Thu, 26 Mar 2009 17:53:14 +0000
> Matthew Garrett <mjg@...hat.com> wrote:
> 
> > Change the default behaviour of the kernel to use relatime for all
> > filesystems. This can be overridden with the "strictatime" mount
> > option.
> 
> NAK this again

NAK but because if we change the default it is better to change it to
the real thing: noatime.

I think this can be solved in userland but perhaps changing this in
kernel would be a stronger message that atime is officially
obsoleted. (and nothing will break, not even mutt users will notice,
and if they really do it won't be anything more than aesthetical)

About the open(destination, O_TRUNC); write; close, I think it's not
worth changing the kernel or the VM in any way to hide buggy
programming like that, to the contrary it's great it was found early
on (instead of being filed as some obscure not reproducible bug lost
in some bugzilla and hitting once in a while with an unlucky
power-loss during boot). But solving this bug with fsync so it works
for writeback mode too, would make me prefer to gamble and run the the
buggy version ;). Not sure if it worth providing any ordering
guarantee more than 'ordered' mode in the long term or some proper
barrier, but at least ordered mode already allows for renaming the
tempfile to be enough and that is clearly the best tradeoff. fsync
really should be used only to avoid total loss of information (like
when we need to avoid losing the delivery of an email after the smpt
client is told the email was already received by the smtp server).

Using fsync to tell the kernel in what order to write is dirty
pagecache data to disk, is as inefficient as driving a car to travel a
10 meters distance, so rightfully people isn't using it for this even
if it's the only way it could work for writeback and ext2 too.
--
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/