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.
interesting idea, but this is not commonly done - in fact many vendors will share cache areas not only across LUNs, and mirrored data, but also with control and code data .. pinning data in cache on the 9990 is also not that common since the amount of cache that gets consumed is something like 3x the LUN or LDEV size .. you've got another issue if you consider multiple LUNs coming from the same vdisk, since i believe the cache controller will attempt to optimize IO caching to the vdisk - not necessarily to the LUN. 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. > 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. 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. --- .je _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
