On Thu, May 06, 2010 at 11:28:37AM +0100, Robert Milkowski wrote: > With the put back of: > > [PSARC/2010/108] zil synchronicity > > zfs datasets now have a new 'sync' property to control synchronous > behaviour. > The zil_disable tunable to turn synchronous requests into asynchronous > requests (disable the ZIL) has been removed. For systems that use that > switch on upgrade > you will now see a message on booting: > > sorry, variable 'zil_disable' is not defined in the 'zfs' module > > Please update your system to use the new sync property. > Here is a summary of the property: > > ------- > > The options and semantics for the zfs sync property: > > sync=standard > This is the default option. Synchronous file system transactions > (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log) > and then secondly all devices written are flushed to ensure > the data is stable (not cached by device controllers). > > sync=always > For the ultra-cautious, every file system transaction is > written and flushed to stable storage by system call return. > This obviously has a big performance penalty. > > sync=disabled > Synchronous requests are disabled. File system transactions > only commit to stable storage on the next DMU transaction group > commit which can be many seconds. This option gives the > highest performance, with no risk of corrupting the pool. > However, it is very dangerous as ZFS is ignoring the synchronous > transaction > demands of applications such as databases or NFS. > Setting sync=disabled on the currently active root or /var > file system may result in out-of-spec behavior or application data > loss and increased vulnerability to replay attacks. > Administrators should only use this when these risks are understood. > > The property can be set when the dataset is created, or dynamically, > and will take effect immediately. To change the property, an > administrator can use the standard 'zfs' command. For example: > > # zfs create -o sync=disabled whirlpool/milek > # zfs set sync=always whirlpool/perrin
I read that this property is not inherited and I can't see why. If what I read is up-to-date, could you tell why? -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
pgpnwVhYvicjy.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
