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: <9534.1305905293@localhost>
Date:	Fri, 20 May 2011 11:28:13 -0400
From:	Valdis.Kletnieks@...edu
To:	d.g.jansen@...glemail.com
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	tytso@....edu
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode

On Thu, 19 May 2011 15:34:46 +0200, Dennis Jansen said:

> Testing:
> I've been using this workaround on my netbook for over six months now.
> It works as expected for me with all software in a Ubuntu 9.10
> environment and saves me at least 0.5 Watt or roughly 10 % battery
> time - without destroying my hard disk. I have seen no negative side
> effects.
> 
> What I didn't test:
> I didn't test this on different platforms and environments. But as
> it's generic code I expect no different behavior. I didn't benchmark
> how this might affect performance due to the additional if() check for
> every fsync call. But as the fsync is rather expensive and not used
> *that* much, I think it should have not noticeable impact.

How much destructive testing did you do?  In the 6 months, how many times did
the system crash (or had the battery pulled out, or whatever) while large
amounts of data were still pending after apps thought they were fsync'ed? How
much crash testing was done against apps that use fsync for ordering or
correctness reasons?

> In short: That it makes laptop_mode work as advertised IHO is no valid
> point against this solution. And if, we could consider a sending a
> printk the first time an fsync is skipped.

That would be the same printk that the user never actually *sees* because your
patch suppressed syslogd's fsync to guarantee it made it to disk, so it was
lost when the system crashed soon thereafter, along with the user's work? ;)

Content of type "application/pgp-signature" skipped