[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49CD5143.1060904@garzik.org>
Date: Fri, 27 Mar 2009 18:20:51 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Theodore Tso <tytso@....edu>, Jeff Garzik <jeff@...zik.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Matthew Garrett <mjg59@...f.ucam.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
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
Theodore Tso wrote:
> On Fri, Mar 27, 2009 at 03:43:03PM -0400, Jeff Garzik wrote:
>> On the other side of the coin, major desktop apps Firefox and
>> Thunderbird already use it: Firefox uses sqlite to log open web pages
>> in case of a crash, and sqlite in turn sync's its journal as any good
>> database app should. [I think tytso just got them to use fdatasync and
>> a couple other improvements, to make this not-quite-so-bad]
>
> I spent a very productive hour-long conversation with the Sqlite
> maintainer last weekend. He's already checked in a change to use
> fdatasync() everywhere, and he's looking into other changes that would
> help avoid needing to do a metadata sync because i_size has changed.
> One thing that will definitely help is if applications send the
> sqlite-specific SQL command "PRAGMA journal_mode = PERSIST;" when they
> first startup the Sqlite database connection. This will cause Sqlite
> to keep the rollback journal file to stick around instead of being
> deleted and then recreated for each Sqlite transaction. This avoids
> at least one fsync() of the directory containing the rollback journal
> file. Combined with the change in Sqlite's development branch to use
> fdatasync() everwhere that fsync() is used, this should definitely be
> a huge improvement.
>
> In addition, Firefox 3.1 is reportedly going to use an union of an
> on-disk database and an in-memory database, and every 15 or 30 minutes
> or so (presumably tunable via some config parameter), the in-memory
> database changes will be synched out to the on-disk database. This
> will *definitely* help a lot, and also help improve SSD endurance.
Definitely, though it will be an interesting balance once user feedback
starts to roll in...
Firefox started doing this stuff because, when it or the window system
or OS crashed, users like my wife would not lose the 50+ tabs they've
opened and were actively using. :)
So it's hard to see how users will react to going back to the days when
firefox crashes once again mean lost work. [referring to the 15-30 min
delay, not fsync(2)]
Jeff
--
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