Wednesday, June 21, 2006, 6:41:50 PM, you wrote:
NP> Torrey McMahon wrote On 06/21/06 10:29,:
>> Roch wrote:
>>> Sean Meighan writes:
>>> > The vi we were doing was a 2 line file. If you just vi a new file,
>>> add > one line and exit it would take 15 minutes in fdsynch. On
>>> recommendation > of a workaround we set
>>> > > set zfs:zil_disable=1
>>> > > after the reboot the fdsynch is now < 0.1 seconds. Now I have no
>>> idea if it was this setting or the fact that we went through a reboot.
>>> Whatever the root cause we are now back to a well behaved file system.
>>> well behaved...In appearance only !
>>> Maybe it's nice to validate hypothesis but you should not
>>> run with this option set, ever., it disable O_DSYNC and
>>> fsync() and I don't know what else.
>>> Bad idea, bad.
>> 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?
I think it could be useful in some cases after all.
zfs-discuss mailing list