Should SQLite users be setting barrier=1?

[Eric Sandeen]

On 07/13/2010 08:47 AM, Dan Kennedy wrote:
> Hi,
> 
> Should sqlite users who are paranoid about losing data
> when hard resets occur be setting the barrier=1 mount
> option with ext3?

barriers should be enabled whenever you wish to ensure a consistent
filesystem post-powerloss, and you have write caches on your drives
which may reorder or lose data when power is lost.

Whether your resets drop power to drive caches, I dunno.

> The situation is that we think SQLite has written data
> to a series of 4K blocks in a file and then called
> fsync() on the file descriptor. After this a hard reset
> occurs. Upon recovery it seems like one of the 4K blocks
> has been zeroed. The others are all fine.

See ext3_sync_file:

        /*
         * In case we didn't commit a transaction, we have to flush
         * disk caches manually so that data really is on persistent
         * storage
         */
        if (needs_barrier)
                blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL,
                                BLKDEV_IFL_WAIT);


so w/o barriers you are not flushing the drive cache and that data will
be lost.

> Happens every now and again under stress testing.
> 
> System is using data=journaled, but not barrier=1.
> 
> Should users also be setting barrier=1 for extra robustness
> in the face of hard resets?

s/extra// - but yes.

-Eric

> Thanks,
> Dan.
> 
> _______________________________________________
> Ext3-users mailing list
> Ext3-users at redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users