Re: [rfc] Ignore Fsync Calls in Laptop_Mode

[D. Jansen]

On Sat, May 21, 2011 at 12:03 AM, torbenh <torbenh@xxxxxx> wrote:
> On Fri, May 20, 2011 at 06:40:49PM +0200, D. Jansen wrote:
>> On Fri, May 20, 2011 at 5:28 PM, Â<Valdis.Kletnieks@xxxxxx> wrote:
>> > 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.
>> >
>> > 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?
>>
>> I don't see the point in verifying the obvious. Of course applications
>> that rely on fsync will lose data.
>> The real problem comes with ordering correctness, which could actually
>> _destroy previous data_ as well.
>> In my scenario (office applications, browsing) I have not hit such a problem.
>
> how about making fsync block until the harddisk spins up ?
> this would also enable you to detect these apps you wouldnt be using in
> laptop mode anyways ?

Very nice idea. I had tried that some time ago. Depending on the error codes I
have, the apps either failed to save and complained to the user - or -
kept trying to fsync again and again. Of course the latter wouldn't
really be a problem unless a race occurs. And we have the benefit of
being honest to user
space and letting them know we are not fsyncing. And the fsync occurs
as soon as we disable laptop mode and plug into AC. I have to try that
out again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/