The theory I am going by is that 10 seconds worth of your synchronous writes is sufficient for the slog. That breaks down if the main pool is the bottleneck.
-r Le 26 sept. 07 à 20:10, Torrey McMahon a écrit : > 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? > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
