ufs2 / softupdates / ZFS / disk write cache

[Ronald Klop]

On Sat, 20 Jun 2009 23:29:26 +0200, Dan Naumov <dan.naumov at gmail.com>  
wrote:

> I have the following setup:
>
> A single consumer-grade 2tb SATA disk: Western Digital Green (model
> WDC WD20EADS-00R6B0). This disk is setup like this:
>
> 16gb root partition with UFS2 + softupdates, containing mostly static  
> things:
> /bin /boot /etc /root /sbin /usr /var and such
>
> a 1,9tb non-redundant zfs pool on top of a slice, it hosts things like:
> /DATA, /home, /usr/local, /var/log and such.
>
> What should I do to ensure (as much as possible) filesystem
> consistency of the root filesystem in the case of the power loss? I
> know there have been a lot of discussions on the subject of
> consumer-level disks literally lying about the state of files in
> transit (disks telling the system that files have been written to disk
> while in reality they are still in disk's write cache), in turn
> throwing softupdates off balance (since softupdates assumes the disks
> don't lie about such things), in turn sometimes resulting in severe
> data losses in the case of a system power loss during heavy disk IO.
>
> One of the solutions that was often brought up in the mailing lists is
> disabling the actual disk write cache via adding hw.ata.wc=0 to
> /boot/loader.conf, FreeBSD 4.3 actually even had this setting by
> default, but this was apparently reverted back because some people
> have reported a write performance regression on the tune of becoming
> 4-6 times slower. So what should I do in my case? Should I disable
> disk write cache via the hw.ata.wc tunable? As far as I know, ZFS has
> a write cache of it's own and since the ufs2 root filesystem in my
> case is mostly static data, I am guessing I "shouldn't" notice that
> big of a performance hit. Or am I completely in the wrong here and
> setting hw.ata.wc=0 is going to adversely affect the write performance
> on both the root partition AND the zfs pool despite zfs using it's own
> write cache?
>
> Another thing I have been pondering is: I do have 2gb of space left
> unused on the system (currently being used as swap, I have 2 swap
> slices, one 1gb at the very beginning of the disk, the other being 2gb
> at the end), which I could turn into a GJOURNAL for the root
> filesystem...

Using gjournal is a very trusted way for a good balance in consistency and  
speed. I don't know about any performance impact of having the journal at  
the other 'end' of the disk than where the fs is. You can try, because  
switching back is possible.

Ronald.