Chris's Wiki :: blog/solaris/ZFSEnticingFeatures Commentshttps://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSEnticingFeatures?atomcommentsDWiki2011-10-29T07:01:08ZRecent comments in Chris's Wiki :: blog/solaris/ZFSEnticingFeatures.By Chris Siebenmann on /blog/solaris/ZFSEnticingFeaturestag:CSpace:blog/solaris/ZFSEnticingFeatures:1db3d4d90f047bd35e9480d954d419a2685c6a91Chris Siebenmann<div class="wikitext"><p>It turns out that ZFS dedup is useless for us in practice. Why is
kind of long so I put it in <a href="https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSDedupMemoryProblem">ZFSDedupMemoryProblem</a>.</p>
<p>My experience is that live upgrades are one of those 'sounds useful
but isn't really' things. A good discussion is too long for a comment,
but fortunately I've already <a href="https://utcc.utoronto.ca/~cks/space/blog/solaris/LiveUpgradeDisinterest">written about it</a>.</p>
<p>(The other part of 'install on new hardware' is that this would be a
test installation done to try things out. This isn't something that I
can do on a production fileserver at all, so I have to put it on test
hardware.)</p>
<p>Our slog situation is complicated enough to not fit within the margins
of this comment. I should probably write at least a summary entry on it.
The short version is that we are in an unusual situation where slogs
don't seem likely to be worth the expense.</p>
<p>As far as I know, bp rewrite is not an announced Solaris 11 feature.
It's been one of those great desires more or less since ZFS was
announced; as far as I know, first Sun and now Oracle has done about
exactly nothing on implementing it.</p>
<p>PS: 24 GB may be typical for fileservers in some environments, but it's
not in ours. Ours have 8 GB and I consider that somewhat wasteful.</p>
</div>2011-10-29T07:01:08ZFrom 69.158.18.227 on /blog/solaris/ZFSEnticingFeaturestag:CSpace:blog/solaris/ZFSEnticingFeatures:ee839713c718cbfcefc77d40bd68275681ae25bdFrom 69.158.18.227<div class="wikitext"><p>One more thing: a major feature that I think a lot of people have been waiting for is the so-called "bp* rewrite" functionality.</p>
<p>It would allow one to remove devices and also change RAID levels (i.e. go from RAIDZ1 to Z2, etc.). This has supposedly been in the works for a while, but no word on it yet. Perhaps Solaris 11?</p>
</div>2011-10-28T21:39:46ZFrom 69.158.18.227 on /blog/solaris/ZFSEnticingFeaturestag:CSpace:blog/solaris/ZFSEnticingFeatures:b6eb26a91f11341d5ccc021df10efe49cdd084ceFrom 69.158.18.227<div class="wikitext"><p>Instead of (only) installing a more recent version of Solaris on separate hardware, you may also want to investigate using Live Upgrade and setting up separate boot environments (BEs) which can be patched while the system is running. Once you're in your maintenance window, you reboot the host into the new BE. If there's an issue you just reboot back into the original BE. Your downtime is your reboot time.</p>
<p>It's a bit of work figuring out the CLI options with UFS root—you need a separate pair of mirrored root disks, or to break your current mirror and patch one half (which can be done automagically)—but quite lovely if you have ZFS root as it leverages snapshots and clones.</p>
<p>For "slog" devices, you don't actually need a big device to get good performance. By default the ZFS Intent Log (ZIL) cannot be more than 50% of RAM, so if your file server is 24 GB (not a lot these days really), you don't need more than a 12 GB SSD. If you buy a 80 GB SLC, you can use 12 GB for the "slog" device and use the rest for a "cache" device.</p>
<p>The topic has come up a few times on the "zfs-discuss" list over the years, and the general consensus that MLC can be fine for "cache" devices, but SLC is preferred for "slog". SandForce SF-1500- and SF-2500/2600-based devices are well-regarded (they usually come with supercaps).</p>
<p>As for ZFS dedupe: still performance issues with it. Have a lot of RAM or a big L2ARC SSD (or both).</p>
</div>2011-10-28T21:37:17ZFrom 138.92.10.18 on /blog/solaris/ZFSEnticingFeaturestag:CSpace:blog/solaris/ZFSEnticingFeatures:5a00dd52028a353d2fbae83c7766623f78cbe347From 138.92.10.18<div class="wikitext"><p>I'd start with Solaris 11. It adds dedupe. :)</p>
<p>It should be noted that any protocol which issues SYNC requests will increase latency times for ZFS, unless a log device is present. Typically NFS clients use SYNC (e.g. VMware ESX(i)), and I believe iSCSI does as well.</p>
</div>2011-10-28T19:37:24ZFrom 198.102.62.250 on /blog/solaris/ZFSEnticingFeaturestag:CSpace:blog/solaris/ZFSEnticingFeatures:ca66651d4ed12675fe72ace6af36ed44218d26ebFrom 198.102.62.250<div class="wikitext"><p>Log device removal is huge. Definitely worth the upgrade! Without it you need more reliable log devices which are very pricey and don't really add much performance (for our workloads) beyond the lower cost SSD's (though the DDRdrive is pretty slick).</p>
<p>The downside is, it's getting hard to find drives targeted at the log workload. You really need only about 2GB of space (most drives are at least 100GB now it seems) and especially not ones with SLC flash (Intel has a 20GB SLC drive now, but it's actually not aimed at Enterprise workloads and have yet to try it out and compare with the X-25E workhorses we've been using).</p>
</div>2011-10-28T19:34:21Z