zfs discuss - May 2010 - Heads Up: zil_disable has expired, ceased to be, ...

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

------------------------

-- Team ZIL.

It should be in build 140.
For a little bit more information on it you might look at
http://milek.blogspot.com/2010/05/zfs-synchronous-vs-asynchronous-io.html


-- 
Robert Milkowski
http://milek.blogspot.com

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 at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100506/b84cd876/attachment.bin>

On 06/05/2010 12:24, Pawel Jakub Dawidek wrote:
> 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?
It is inherited, this changed as a result of the PSARC review.

-- 
Darren J Moffat

On 06/05/2010 12:24, Pawel Jakub Dawidek wrote:
> 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?
>    
It is inherited. Sorry for the confusion but there was a discussion if 
it should or should not be inherited, then we propose that it shouldn''t
but it was changed again during a PSARC review that it should.

And I did a copy''n''paste here.

Again, sorry for the confusion.

-- 
Robert Milkowski
http://milek.blogspot.com

On 06/05/2010 13:12, Robert Milkowski wrote:
> On 06/05/2010 12:24, Pawel Jakub Dawidek wrote:
>> 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?
>
> It is inherited. Sorry for the confusion but there was a discussion if 
> it should or should not be inherited, then we propose that it 
> shouldn''t but it was changed again during a PSARC review that it
should.
>
> And I did a copy''n''paste here.
>
> Again, sorry for the confusion.
>
Well, actually I did copy''n''paste a proper page as it
doesn''t say
anything about inheritance.

Nevertheless, yes it is inherited.

-- 
Robert Milkowski
http://milek.blogspot.com

On Thu, May 06, 2010 at 01:15:41PM +0100, Robert Milkowski
wrote:
> On 06/05/2010 13:12, Robert Milkowski wrote:
> >On 06/05/2010 12:24, Pawel Jakub Dawidek wrote:
> >>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?
> >
> >It is inherited. Sorry for the confusion but there was a discussion if 
> >it should or should not be inherited, then we propose that it 
> >shouldn''t but it was changed again during a PSARC review that
it should.
> >
> >And I did a copy''n''paste here.
> >
> >Again, sorry for the confusion.
> >
> Well, actually I did copy''n''paste a proper page as it
doesn''t say
> anything about inheritance.
> 
> Nevertheless, yes it is inherited.
Yes, your e-mail didn''t mention that and I wanted to clarify if what I
read in PSARC changed or not. Thanks:)

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100506/99f145cc/attachment.bin>

On 5/6/10 5:28 AM, Robert Milkowski wrote:
> 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.
Is there a way (short of DTrace) to write() some data and get notified 
when the corresponding txg is committed? Think of it as a poor man''s 
group commit.

Wes Felter

On Thu, May 06, 2010 at 03:30:05PM -0500, Wes Felter
wrote:
> On 5/6/10 5:28 AM, Robert Milkowski wrote:
> 
> >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.
> 
> Is there a way (short of DTrace) to write() some data and get
> notified when the corresponding txg is committed? Think of it as a
> poor man''s group commit.
fsync(2) is it.  Of course, if you disable sync writes then there''s no
way to find out for sure.  If you need to know when a write is durable,
then don''t disable sync writes.

Nico
--

On 06/05/2010 21:45, Nicolas Williams wrote:
> On Thu, May 06, 2010 at 03:30:05PM -0500, Wes Felter wrote:
>    
>> On 5/6/10 5:28 AM, Robert Milkowski wrote:
>>
>>      
>>> 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.
>>>        
>> Is there a way (short of DTrace) to write() some data and get
>> notified when the corresponding txg is committed? Think of it as a
>> poor man''s group commit.
>>      
> fsync(2) is it.  Of course, if you disable sync writes then
there''s no
> way to find out for sure.  If you need to know when a write is durable,
> then don''t disable sync writes.
>
> Nico
>    
There is one way - issue a sync(2) - even with sync=disabled it will 
sync all filesystems and then return.
Another workaround would be to create a snapshot...

However I agree with Nico - if you don''t need sync=disabled then
don''t
use it.

Someone else mentioned that yet another option like sync=fsync-only 
would be useful so all would be async but fsync() - but frankly I''m not
convinced as it would require a support in your application but at this 
point you already have a full control of the behavior without need for 
sync=disabled.

-- 
Robert Milkowski
http://milek.blogspot.com