linux-kernel - Re: [rfc] Ignore Fsync Calls in Laptop

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: <BANLkTincvGV735PKb60Kg0dLX6a1CZ-iNA@mail.gmail.com>
Date:	Thu, 26 May 2011 09:01:49 +0200
From:	"D. Jansen" <d.g.jansen@...glemail.com>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, tytso@....edu
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode

On Wed, May 25, 2011 at 8:50 AM, Oliver Neukum <oneukum@...e.de> wrote:
>
> Am Mittwoch, 25. Mai 2011, 02:00:03 schrieb Dave Chinner:
> > Oh, you're talking about application level write ordering.
(...)
> > Besides, having to work out how to handle subtle application write
> > ordering bugs because you changed fsync semantics is simply another
> > reason for not changing behaviour in the first place.
>
> Sure. I'd say changing the behavior is right out. The question is whether
> we want an additional "superlaptop"-mode.

Exactly. 0.5 Watts is a lot of energy on a modern system. And on some
systems with proper link power management in sata and pcie it will be
even higher (~1 Watt I think). Think not only of the work that will be
lost if the system crashes (unlikely), but also of the work that could
never be done because the battery was gone (a certainty).
>
> And even in this case it seems to me that fsync() cannot be reduced to
> a nop because of ordering constraints. But perhaps we should then consider
> exporting an ordering primitive to user space.

That seems to be the big ordering issue. I had always assumed that
user space writes (by the same app to the same file) would be
committed in order. Is that really not the case?

Wouldn't most app programmers assume ordering? Wouldn't that always
possibly be an issue? Or do all the apps that require ordered writes
use fsync. There will surely be some who require ordering but don't
fsync. And without ordering, some apps won't be able to avoid fsync
without data safety issues.

It would seem that even ordering writes by default could not be a data
safety issue. But I guess performance would be affected negatively in
some cases. And behavior shouldn't be changed. So yes, it seems an
ordering primitive would be a good idea.
--
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/