On 11/ 9/11 01:42 AM, Edward Ned Harvey wrote:
Ok, so the risk is about ZFS server unexpexted reboot (crash, power,
I know a lot of people will say "don't do it," but that's only partial
truth. The real truth is:
At all times, if there's a server crash, ZFS will come back along at next
boot or mount, and the filesystem will be in a consistent state, that was
indeed a valid state which the filesystem actually passed through at some
moment in time. So as long as all the applications you're running can
accept the possibility of "going back in time" as much as 30 sec,
an ungraceful ZFS crash, then it's safe to disable ZIL (set
Let's say assuming ZFS is stable (we never had problems on any
opensolaris/openindiana systems, except ones with CIFS services
enabled..), the server is running in well power-protected rack and on
Sun's legendary reliable hardware (e.g. X4540), doing "sync=disabled"
thing could be acceptable option for test lab environments.
Long story short, if you're willing to allow your server and all of the
dependent clients to go back in time as much as 30 seconds, and you're
willing/able to reboot everything that depends on it, then you can accept
That's a lot of thinking. And a lot of faith or uncertainty. And in your
case, it's kind of inconvenient. Needing to manually start your NFS share
every time you reboot your ZFS server.
The safer/easier thing to do is add dedicated log devices to the server
instead. It's not as fast as running with ZIL disabled, but it's much
faster than running without a dedicated log.
and for production use ZIL dedicated device is required.
I was thinking about STEC ZeusRAM, but unfortunately it's SAS only
device, and it won't make into X4540 (SATA ports only), so another
option could be STEC MACH16iops (50GB SLC SATA SSD).
When choosing a log device, focus on FAST. You really don't care about
size. Even 4G is usually all you need.
Thanks to all for sharing your ideas and suggestions.
zfs-discuss mailing list