|
|
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
pjd@xxxxxxxxxxx http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
_______________________________________________
zfs-discuss mailing list
zfs-discuss@xxxxxxxxxxxxxxx
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
|
|