Tim Haley writes:
> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
> This information is Copyright (c) 2010, Oracle and/or its affiliates.
> All rights
> reserved.
> 1. Introduction
> 1.1. Project/Component Working Name:
> zil synchronicity
> 1.2. Name of Document Author/Supplier:
> Author: Neil Perrin
> 1.3 Date of This Document:
> 01 April, 2010
>
> 4. Technical Description
>
> I am sponsoring the following fast-track for Robert Milkowski and Neil
> Perrin. It introduces a new dataset property for controlling
> synchronous behavior. The case requests micro/patch binding.
>
> 1. Summary
>
> Provide administrators of zfs with the ability to control
> the behavior of synchronous requests (e.g. fsync, O_DSYNC).
> In particular, new capabilities are proposed to 1) delay executing the
> synchronous request and 2) force all requests to be synchronous.
> The current POSIX behavior of ensuring all synchronous requests are
> written to stable storage would remain the default.
>
> 2. Background
>
> Currently ZFS have no official control over synchronous behaviour.
> However, unfortunately, a zfs module switch (zil_disable) has been
> fairly well publicized to disable the ZIL, the code which enforces
> synchronous requests. This is a global kernel variable and so affects
> all file systems within all pools.
>
> It should be noted that ZFS pools are always consistent. That is, the
> intent log is not required for pool integrity. This is due to the
> transactional behavior of ZFS and in particular its transaction
> group commit (txg) model. What the ZIL does is simply to ensure that
> synchronous write requests are committed to stable storage prior to
> returning from the system call.
>
> There are reasonable cases where the administrator understands the
> consequences of disabling synchronous behavior. For example, if the
> system crashes they start again from scratch. This is quicker
> than enabling synchronous behavior.
>
> There are also reasons an administrator may want to enable synchronous
> behavior for all writes. This might help debug an issue where
> synchronous writes are needed.
>
> 3. Proposal
>
> The options and semantics proposed for a new zfs dataset property:
>
> sync=default
> 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 would
> be written and flushed to stable storage by system call return.
> This obviously has a big performance penalty.
>
It's possible that sync=always could be used by NFSD become helpful for
linux client behavior. So I would say :
This obviously has a significant performance impact.
More below
> 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 will give the
> highest performance. However, it is very dangerous as ZFS
> would be ignoring the synchronous transaction demands of
> applications such as databases or NFS. 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
>
> The current value of 'sync' can be retrieved in the usual manner
> with 'zfs get sync' or 'zfs list -o sync'. The sync property is not
> inherited from parent datasets.
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> ON
> 6.5. ARC review type: FastTrack
> 6.6. ARC Exposure: open
>
A zvol can accept DKIOCSETWCE which has similar effect and
counter effect. We should be specifiying what the
interactions will be.
I guess that the non default dataset sync flag will render
DKIOCSETWCE a noop.
Will the sync flag impact the return value of a DKIOCGETWCE ?
-r
_______________________________________________
opensolaris-arc mailing list
[email protected]
