Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread Robert Milkowski

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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread Nicolas Williams
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
-- 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread Wes Felter

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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread Pawel Jakub Dawidek
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
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgp3bNocGiTgs.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread Robert Milkowski

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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread Robert Milkowski

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


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread 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, this changed as a result of the PSARC review.

--
Darren J Moffat
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Heads Up: zil_disable has expired, ceased to be, ...

2010-05-06 Thread Pawel Jakub Dawidek
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