> 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

Reply via email to