Re: SQLite and ext3 journalling mode
Ric Wheeler <[email protected]> Wed, 08 Dec 2010 08:26:27 -0500
| Newsgroups | gmane.comp.file-systems.ext3.user |
|---|---|
| Message-ID | <[email protected]> |
On 12/08/2010 02:02 PM, Miller, Mike (OS Dev) wrote: > >> -----Original Message----- >> From: [email protected] [mailto:ext3-users- >> [email protected]] On Behalf Of Ric Wheeler >> Sent: Wednesday, December 08, 2010 11:08 AM >> To: Richard Hipp >> Cc: [email protected] >> Subject: Re: SQLite and ext3 journalling mode >> >> On 12/08/2010 11:56 AM, Richard Hipp wrote: >>> >>> On Wed, Dec 8, 2010 at 11:25 AM, Ric Wheeler<[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 12/08/2010 06:52 AM, Dan Kennedy wrote: >>> >>> >>> 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. >>> >>> >>> Thanks, Ric. Yes, we are numbered among the "annoying users". Based >> on what >>> you are telling us, we'll recommend that people use data=ordered, >> barrier=1 > Just as an FYI, not all HW vendors enable the drive write cache especially on array controllers. In those cases barriers do nothing. > > -- mikem > > Right - upstream has been working to make sure that we can default to barriers on and not see a performance hit for devices like arrays that don't need them ... Ric