> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Evaldas Auryla
> I'm trying to evaluate what are the risks of running NFS share of zfs
> dataset with sync=disabled property. The clients are vmware hosts in our
> environment and server is SunFire X4540 "Thor" system. Though general
> recommendation tells not to do this, but after testing performance with
> default setting and sync=disabled - it's night and day, so it's really
> tempting to do sync=disabled ! Thanks for any suggestion.
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).
In your case, you have vm's inside the ZFS filesystem. In the event ZFS
crashes ungracefully, you don't want the VM disks to "go back in time" while
the VM's themselves are unaware anything like that happened. If you run
with sync=disabled, you want to ensure your ZFS / NFS server doesn't come
back up automatically. If ZFS crashes, you want to force the guest VM's to
crash. Force power down the VM's, then bring up NFS, remount NFS, and
reboot the guest VM's. All the guest VM's will have gone back in time, by
as much as 30 sec. This is generally acceptable for things like web servers
and file servers and windows VMs in a virtualized desktop environment etc.
It's also acceptable for things running databases, as long as all the DB
clients can go back in time (reboot them whatever). It is NOT acceptable if
you're processing credit card transactions, or if you're running a
mailserver and you're unwilling to silently drop any messages, or ... stuff
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.
When choosing a log device, focus on FAST. You really don't care about
size. Even 4G is usually all you need.
zfs-discuss mailing list