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
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
