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