ZFS vfs.zfs.cache_flush_disable and ZIL reliability

Marcus Reid marcus at blazingdot.com
Thu Mar 17 07:16:19 UTC 2011


Hi,

I was just doing some reading about write barriers being used in
filesystems to ensure that the journal is complete to prevent data
corruption on unexpected failure.  This is done by flushing the
disk cache after making a journal entry and before writing to
the rest of the fs.

I figured I'd look to see what different filesystems do for this.

In Linux, ext3 and ext4 have a "barrier" mount option which controls
this.  It's the subject of much debate and was turned off by default
until 2.6.28 in ext4 (it's still off by default in ext3) because it
can significantly reduce performance in some workloads.

FreeBSD g_journal is not configurable -- it flushes the cache and
looks to be safe.  My only worry is that it looks like it might even
flush it too often, but there may be a reason for the extra flush.

I'm having a hard time finding where the rubber meets the road with
the ZFS ZIL though (one does not just walk into Mordor.)  I got as
far as finding the vfs.zfs.cache_flush_disable sysctl which sets
zfs_nocacheflush which is referenced in zil_add_block() in zil.c
but haven't found where the actual flushing happens.  Can someone
who is more familiar with it comment on whether this is happening?

Thanks,

Marcus


More information about the freebsd-fs mailing list