On Wed, Sep 26, 2007 at 02:10:39PM -0400, Torrey McMahon wrote:
> Albert Chin wrote:
> > On Tue, Sep 25, 2007 at 06:01:00PM -0700, Vincent Fox wrote:
> >   
> >> I don't understand.  How do you
> >>
> >> "setup one LUN that has all of the NVRAM on the array dedicated to it"
> >>
> >> I'm pretty familiar with 3510 and 3310. Forgive me for being a bit
> >> thick here, but can you be more specific for the n00b?
> >>     
> >
> > If you're using CAM, disable NVRAM on all of your LUNs. Then, create
> > another LUN equivalent to the size of your NVRAM. Assign the ZIL to
> > this LUN. You'll then have an NVRAM-backed ZIL.
> 
> You probably don't have to create a LUN the size of the NVRAM either. As 
> long as its dedicated to one LUN then it should be pretty quick. The 
> 3510 cache, last I checked, doesn't do any per LUN segmentation or 
> sizing. Its a simple front end for any LUN that is using cache.
> 
> Do we have any log sizing guidelines yet? Max size for example?

That's a really good question -- and the answer essentially depends on the
bandwidth of the underlying storage and the rate of activity to the ZIL.
Both of these questions can be tricky to answer -- and the final answer
also depends on how much headroom you desire.  (That is, what drop
in bandwidth and/or surge in ZIL activity does one want to be able to
absorb without sacrificing latency?)  For the time being, the easiest
way to answer this question is to try some sizes (with 1-2 GB being a
good starting point), throw some workloads at it, and monitor both your
delivered performance and the utilization reported by tools like iostat...

        - Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to