> 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 like that. 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. 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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
