> From: Cooper Hubbell [mailto:cooper...@gmail.com] > > My system is currently using LSI 9211 HBAs with Crucial M4 SSDs for > ZIL/L2ARC. I have used LSIUTIL v1.63 to disable the write cache on the two > > Unfortunately, the SATA write cache can only be turned on or off at the > controller level with LSIUTIL.
You don't want to disable the on-disk cache*. You only want to disable the on-controller writeback. Typically the on-disk is something like 16M, 32M or so. The on-controller is typically 256M, 512M, or greater. That might help you identify which cache you're looking at, in any given situation. * Most disks are happy to buffer writes, and honor the OS request to flush. Assuming this is the case, it's definitely what you want, as it significantly boosts the performance of any given disk - it's able to internally optimize it's head movements and so forth, it's got the right data in the right buffer at the right time, so it doesn't need to waste time on another rotation waiting for some buffer to be ready, etc. Unfortunately, not all disks are well behaved. I don't know how to verify for certain that your disks are well behaved, but some drives acknowledge the flush request, and lie about having completed the request, and then your data is at risk. The easiest way to avoid that problem is to only buy sun(oracle) hardware that's sold with solaris, because you know for sure they tested it. Anyone else, maybe. I dare say, probably you're fine, but only "probably." > In a case where the SSD ZIL and L2ARC are on > the same controller as pool HDDs, is it still recommended that the cache be > disabled? Controller writeback. As long as you have SSD ZIL, then yes, disable controller writeback. > My other thought is that the cache to which LSIUTIL is referring is > located on the controller and that the write cache on the individual disks is > still active. This excerpt shows the interactive prompts of LSIUTIL during > and > after disabling the cache: The controller certainly is smart enough to enable/disable on-controller writeback on a per-volume basis (and you've got one volume per disk). So you're right, this certainly makes it confusing to know which cache you're talking about in any given context. I suspect your controller is probably only letting you configure the controller writeback via LSIUTIL. The ironic thing is - With this controller in between your CPU and your storage, it's only introducing additional buffers and chips that you're going out of your way to disable. And it's adding a layer of complexity, formatting the drive with proprietary headers, and reducing your access to the individual actual drives. The ironic thing is that you're better off to have no controller, and instead use a simple, dumb, standard SATA/SAS bus. It's both faster, more reliable, and more compatible. But maybe you don't have that option. > SATA Write Caching: [0=Disabled, 1=Enabled, default is 1] 0 Tough one. I don't know. Generally I would say controllers only give you control over the controller writeback, but the way that's written, it certainly sounds like it's talking about the disk. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss