On Tue, Jul 10, 2007 at 12:43:13PM -0400, Jonathan Edwards wrote: > > On Jul 10, 2007, at 12:01, Albert Chin wrote: > > > Dunno if this is the correct forum but any plans to update the 6140 > > firmware to allow specifying how much of the 6140 NVRAM can be > > dedicated to each LUN? This would allow dedicating some of the NVRAM > > to the ZIL and the remaining to the existing LUNs on the system. > > ... > > much of zfs design is currently aimed at offloading caching > strategies back onto the host, and simply offloading the zil onto a > dedicated cache friendly device may not necessarily yield the types > of gains that some are expecting to see .. the real benefit that i > see here is extending the cache strategies on the host side and > possibly the future integration of the filesystem directly onto the > host controller - that seems like a more lucrative endeavor to me.
Once b68 is released, we plan to run tests with ZIL disabled, a RAM-backed ZIL using ramdiskadm(1m), and a NVRAM-backed ZIL using the NVRAM on the 6140. Early on, we did see a noticeable difference with ZIL disabled. So, I'm thinking a RAM-backed ZIL should move us closer to that number. > > Currently, if one wants ZIL in NVRAM, the 6140 NVRAM must be disabled > > on all LUNs except for the LUN being used for the ZIL, where one can > > dedicate all the NVRAM. > > right - i've been tracking it .. with the 6140 though it seems like > it would be a waste since for your normal data LUNs you might be > better off with non-RAID devices if you're planning on using raidz > or any of the self healing pieces .. so you're really paying a lot > of money for an engenio raid ctlr you're not going to use that > much, and for cache that you're attempting to throw at the zil to > offload the design inefficiencies there in the current incarnation. Well, we already bought the 6140 so ... :) And, we are using non-RAID devices. We're just using the 6140 as a JBOD since we want RAID-Z2. Hopefully one day Sun comes out with a better hardware combo using ZFS to compete with Netapp. > now if you do create RAID LUNs for the non zil devices and choose > not to use the array cache - your performance there may be terrible > if you're not very well block aligned (the controller does a decent > job of coalescing IO in cache to get more efficient full stripe > commits to and from the drives with the write cache turned on), and > your R/M/W numbers would probably reflect this - given the fact > that zfs blocksizes are dynamic (up to 128K) based on the > application workload and the size or frequency of the txg commit .. > you may find that different applications will perform quite > differently here. Yeah, I thought about this. That's why I kinda want to leave some NVRAM for the LUNs. But, that's not an option. -- albert chin ([EMAIL PROTECTED]) _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
