Did I miss something on this thread? Was the root cause of the 15-minute fsync every actually determined?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of eric kustarz Sent: Wednesday, June 21, 2006 2:12 PM To: [EMAIL PROTECTED] Cc: zfs-discuss@opensolaris.org; Torrey McMahon Subject: Re: [zfs-discuss] 15 minute fdsync problem and ZFS: Solved 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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
