Date: Fri, 18 Jan 2013 12:12:11 -0800 From: Dieter BSD <dieterbsd@gmail.com> To: freebsd-hackers@freebsd.org Cc: gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org Subject: Re: IBM blade server abysmal disk write performances Message-ID: <CAA3ZYrBV9f%2BcHx4jvS0UKTr%2Bp7eNUBA0S2%2Bv9oZAHqwm9VBOWw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Wojciech writes: > If computer have UPS then write caching is fine. even if FreeBSD crash, > disk would write data That is incorrect. A UPS reduces the risk, but does not eliminate it. It is impossible to completely eliminate the risk of having the write cache on. If you care about your data you must turn the disk's write cache off. If you are using the drive in an application where the data does not matter, or can easily be regenerated (e.g. disk duplication, if it fails, just start over), then turning the write cache on for that one drive can be ok. There is a patch that allows turning the write cache on and off on a per drive basis. The patch is for ata(4), but should be possible with other drivers. camcontrol(8) may work for SCSI and SAS drives. I have yet to see a USB-to-*ATA bridge that allows turning the write cache off, so USB disks are useless for most applications. But for most applications, you must have the write cache off, and you need queuing (e.g. TCQ or NCQ) for performance. If you have queuing, there is no need to turn the write cache on. It is inexcusable that FreeBSD defaults to leaving the write cache on for SATA & PATA drives. At least the admin can easily fix this by adding hw.ata.wc=0 to /boot/loader.conf. The bigger problem is that FreeBSD does not support queuing on all controllers that support it. Not something that admins can fix, and inexcusable for an OS that claims to care about performance.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA3ZYrBV9f%2BcHx4jvS0UKTr%2Bp7eNUBA0S2%2Bv9oZAHqwm9VBOWw>