Neil Perrin wrote:
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?
It is similar in the sense that it speeds up the file system.
Using fastfs can be much more dangerous though as it can lead
to a badly corrupted file system as writing meta data is delayed
and written out of order. Whereas disabling the ZIL does not affect
the integrity of the fs. The transaction group model of ZFS gives
consistency in the event of a crash/power fail. However, any data that
was promised to be on stable storage may not be unless the transaction
group committed (an operation that is started every 5s).
We once had plans to add a mount option to allow the admin
to control the ZIL. Here's a brief section of the RFE (6280630):
sync={deferred,standard,forced}
Controls synchronous semantics for the dataset.
When set to 'standard' (the default), synchronous
operations
such as fsync(3C) behave precisely as defined in
fcntl.h(3HEAD).
When set to 'deferred', requests for synchronous
semantics
are ignored. However, ZFS still guarantees that ordering
is preserved -- that is, consecutive operations reach
stable
storage in order. (If a thread performs operation A
followed
by operation B, then the moment that B reaches stable
storage,
A is guaranteed to be on stable storage as well.) ZFS
also
guarantees that all operations will be scheduled for
write to
stable storage within a few seconds, so that an
unexpected
power loss only takes the last few seconds of change
with it.
When set to 'forced', all operations become synchronous.
No operation will return until all previous operations
have been committed to stable storage. This option
can be
useful if an application is found to depend on
synchronous
semantics without actually requesting them; otherwise, it
will just make everything slow, and is not recommended.
Of course we would need to stress the dangers of setting 'deferred'.
What do you guys think?
Neil.
Scares me, and it seems we should wait until people are demanding it and
we *have* to do it (if that time ever comes) - that is, we can't squeeze
any more performance gain out of the 'standard' method.
If problems do occur because of 'deferred' mode, once i wrap-up zpool
history, we'll have that they set this logged to disk.
eric
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
