Date: Wed, 16 Mar 2011 23:16:18 -0800 From: Marcus Reid <marcus@blazingdot.com> To: freebsd-fs@freebsd.org Subject: ZFS vfs.zfs.cache_flush_disable and ZIL reliability Message-ID: <20110317071618.GB49199@blazingdot.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110317071618.GB49199>