Re: SQLite and ext3 journalling mode
Ric Wheeler <[email protected]> Wed, 08 Dec 2010 11:25:06 -0500
| Newsgroups | gmane.comp.file-systems.ext3.user |
|---|---|
| Message-ID | <[email protected]> |
On 12/08/2010 06:52 AM, Dan Kennedy wrote: > On 12/07/2010 04:31 AM, Ted Ts'o wrote: >> On Tue, Dec 07, 2010 at 01:42:08AM +0700, Dan Kennedy wrote: >>> >>> Are SQLite users that are worried about losing data that has been >>> committed (fsynced) better off setting data=journal than >>> data=ordered (or even data=writeback)? >> >> Well, they won't be better off a data integrity point of view. >> Depending on how SQLite is configured, and how many fsync's are issued >> by SQLite in response to application queries, and depending on your >> background workload by other applications, using data=journal *might* >> be a performance win. >> >> In general, though, if you have background workloads that are >> downloading torrents, data=journal is going to hurt a lot. So I don't >> recommend it except for fairly specialized deployments where there's >> only one primary user of the file system. > > Thanks. But to be clear, is data=ordered better than data=writeback > wrt. data integrity following a power failure? > > Regards, > Dan. > Data integrity can mean a couple of different things. If you are file system meta-data centric (i.e., a file system developer or just worried about having to run fsck after a crash to repair the file system), then both options *should* be equivalent. If you are one of those annoying users who define data integrity to include those annoying details like will my file have garbage in it after a crash that will make my DB or other app puke, then data ordered is clearly more robust. Note that most distributions (including RHEL) support & focus testing only ordered mode.... Hope this helps :) Ric