[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49CD891A.7030103@rtr.ca>
Date: Fri, 27 Mar 2009 22:19:06 -0400
From: Mark Lord <lkml@....ca>
To: Jeff Garzik <jeff@...zik.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Matthew Garrett <mjg59@...f.ucam.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Theodore Tso <tytso@....edu>,
Andrew Morton <akpm@...ux-foundation.org>,
David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.29
Jeff Garzik wrote:
> Linus Torvalds wrote:
>> Of course, your browsing history database is an excellent example of
>> something you should _not_ care about that much, and where performance
>> is a lot more important than "ooh, if the machine goes down suddenly,
>> I need to be 100% up-to-date". Using fsync on that thing was just
>> stupid, even
>
> If you are doing a ton of web-based work with a bunch of tabs or windows
> open, you really like the post-crash restoration methods that Firefox
> now employs. Some users actually do want to checkpoint/restore their
> web work, regardless of whether it was the browser, the window system or
> the OS that crashed.
>
> You may not care about that, but others do care about the integrity of
> the database that stores the active FF state (Web URLs currently open),
> a database which necessarily changes for each URL visited.
..
fsync() isn't going to affect that one way or another
unless the entire kernel freezes and dies.
Firefox locks up the GUI here from time to time,
but the kernel still flushes pages to disk,
and even more quickly when alt-sysrq-s is used.
Cheers
--
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/
Powered by blists - more mailing lists