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 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). -- 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