Hello Neil,
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.
--
Best regards,
Robertmailto:[EMAIL PROTECTED]
http://milek.blogspot.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
