On 08 November, 2011 - Edward Ned Harvey sent me these 2,9K bytes: > > 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).
Client writes block 0, server says OK and writes it to disk. Client writes block 1, server says OK and crashes before it's on disk. Client writes block 2.. waaiits.. waiits.. server comes up and, server says OK and writes it to disk. Now, from the view of the clients, block 0-2 are all OK'd by the server and no visible errors. On the server, block 1 never arrived on disk and you've got silent corruption. Too bad NFS is resilient against servers coming and going.. /Tomas -- Tomas Forsman, st...@acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Umeå `- Sysadmin at {cs,acc}.umu.se _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
