Hello Neil,

Wednesday, June 21, 2006, 8:15:54 PM, you wrote:


NP> Robert Milkowski wrote On 06/21/06 11:09,:
>> Hello Neil,
>>>>Why is this option available then? (Yes, that's a loaded question.)
>> 
>> NP> I wouldn't call it an option, but an internal debugging switch that I
>> NP> originally added to allow progress when initially integrating the ZIL.
>> NP> As Roch says it really shouldn't be ever set (as it does negate POSIX
>> NP> synchronous semantics). Nor should it be mentioned to a customer.
>> NP> In fact I'm inclined to now remove it - however it does still have a use
>> NP> as it helped root cause this problem.
>> 
>> Isn't it similar to unsupported fastfs for ufs?

NP> It is similar in the sense that it speeds up the file system.
NP> Using fastfs can be much more dangerous though as it can lead
NP> to a badly corrupted file system as writing meta data is delayed
NP> and written out of order. Whereas disabling the ZIL does not affect
NP> the integrity of the fs. The transaction group model of ZFS gives
NP> consistency in the event of a crash/power fail. However, any data that
NP> was promised to be on stable storage may not be unless the transaction
NP> group committed (an operation that is started every 5s).

NP> We once had plans to add a mount option to allow the admin
NP> to control the ZIL. Here's a brief section of the RFE (6280630):

NP>          sync={deferred,standard,forced}

NP>                  Controls synchronous semantics for the dataset.

NP>                  When set to 'standard' (the default), synchronous 
operations
NP>                  such as fsync(3C) behave precisely as defined in
NP>                  fcntl.h(3HEAD).

NP>                  When set to 'deferred', requests for synchronous semantics
NP>                  are ignored.  However, ZFS still guarantees that ordering
NP>                  is preserved -- that is, consecutive operations reach 
stable
NP>                  storage in order.  (If a thread performs operation A 
followed
NP>                  by operation B, then the moment that B reaches stable 
storage,
NP>                  A is guaranteed to be on stable storage as well.)  ZFS also
NP>                  guarantees that all operations will be scheduled for write 
to
NP>                  stable storage within a few seconds, so that an unexpected
NP>                  power loss only takes the last few seconds of change with 
it.

NP>                  When set to 'forced', all operations become synchronous.
NP>                  No operation will return until all previous operations
NP>                  have been committed to stable storage.  This option can be
NP>                  useful if an application is found to depend on synchronous
NP>                  semantics without actually requesting them; otherwise, it
NP>                  will just make everything slow, and is not recommended.

NP> Of course we would need to stress the dangers of setting 'deferred'.
NP> What do you guys think?

I think it would be really useful.
I found myself many times in situation that such features (like
fastfs) were my last resort help.

The same with txg_time - in some cases tuning it could probably be
useful. Instead of playing with mdb it would be much better put into
zpool/zfs or other util (and if possible made per fs not per host).


-- 
Best regards,
 Robert                            mailto:[EMAIL PROTECTED]
                                       http://milek.blogspot.com

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

Reply via email to