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, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
