On 11/ 9/11 01:42 AM, Edward Ned Harvey wrote:
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,
following
an ungraceful ZFS crash, then it's safe to disable ZIL (set
sync=disabled).
Ok, so the risk is about ZFS server unexpexted reboot (crash, power, hardware problem..).
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
the sync=disabled

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.
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.
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.
When choosing a log device, focus on FAST.  You really don't care about
size.  Even 4G is usually all you need.

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).

Thanks to all for sharing your ideas and suggestions.

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to