Robert Milkowski wrote On 06/28/06 15:52,:
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 over-whelming consensus was that it would be useful. So I'll go ahead and
put that on my to do list.
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).
This one I'm less sure about. I have certainly tuned txg_time myself to
force certain situations, but I wouldn't be happy exposing the inner workings
of ZFS - which may well change.
Neil
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
