> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Gregory Gee > > Prior to pool version 19, mirroring the log device is highly > recommended. > > I have the following. > > This system is currently running ZFS pool version 14. > > This really worries me. For a home server, mirrored SSD ZIL is > pricey. I assume this means upgrading to a dev version? What do > people do now for upgrades?
Before anything else, a clarification of terminology: Every pool has a ZIL. The ZIL by default is stored on disk within the primary pool. You are not talking about adding a ZIL; you are talking about adding a dedicated log device. If you look at opensolaris.org, under the "download" page, you'll see a section for "Developer builds." There it says two things: There are instructions to upgrade your existing installation in-place, and there is a link http://genunix.org to download the latest developer build in ISO format, for a fresh installation. (The latest is b134, which is about 4 months old.) My personal experience is that the upgrade process is a little bit shaky. Nothing fatal happened, but the system didn't seem quite right afterward. So it's a good idea to backup before doing an upgrade. Another option, since this is your home server: I bet you're not processing credit card transactions. I bet you don't have a compute farm using this as a backend datastore. I bet it's not a mail server, and even more certainly, not a mail server for critical information. etc. You might just consider disabling the ZIL. If you run with ZIL disabled, then your sync writes behave as async writes, which means, it is faster than you could possibly hope even if you had the dedicated log device. The only risk is possibly 30 seconds worth of sync writes leading up to an ungraceful system crash ... but even if you have the ZIL (dedicated log or built-in to pool), then 30 sec of async writes would be at risk anyway. If you're not carefully and strictly paying attention and strictly obsessively controlling your applications to distinguish between sync and async writes, I bet you don't care about the distinction. So just run with your ZIL disabled. For all you knew, your application might have been using async writes anyway, right? > Then, when trying to figure out the size if the SSD, I got this from > the guide as well. > > The maximum size of a log device should be approximately 1/2 the size > of physical memory because that is the maximum amount of potential in- > play data that can be stored. I'll make this even more shocking: Since the maximum you could possibly store in ZIL is 30sec, just calculate the speed of your device and see how many GB that is. In an unrealistic super computer fast world, that would be 32G. Realistically, it's more like 4-6G for extreme heavy usage on real devices. Your system is simply incapable of using more than that. > I don't think I can get SSD that small. It seems like a waste of > larger SSD now. Is there a way to make better use of the SDD by > partitioning? I have two pools, could I partition the SSD to have > each partition as a ZIL for the different pools? Any other creative > uses? Yes. In a high performance environment, people generally acknowledge the waste of space, and simply don't use most of their SSD. You can "format" and "fdisk" and "partition" your SSD, to create smaller slices. Then you can use a slice for log, and a slice for cache. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
