I am wondering about the use of fsync() on journal'd file systems as described below. Shouldn't there be much less use of (or very little use) of fsync() on these types of systems? Let the journal layer due its job and not force it within cyrus? This would likely save a lot of system overhead. It makes sense to use on non-journal'd fs. I also wonder whether modern arrays even respect FULLFSYNC given their more complex nature and I/O scheduling algorithms. It may be time that fsync() (and fcntl(F_FULLFSYNC)) have become moot since there is likely little way to influence, in an effective targeted way, I/O behavior in complex environments these days. /mrg On Nov 19, 2007, at 23:40, Andrew McNamara wrote: >>> In production releases of ZFS fsync() essentially triggers sync() >>> (fixed in >>> Solaris Next). > [...] >> Skiplist requires two fsync calls per transaction (single >> untransactioned actions are also one transaction), and it >> also locks the entire file for the duration of said >> transaction, so you can't have two writes happening at >> once. I haven't built Cyrus on our Solaris box, so I don't >> know if it uses fcntl there, it certainly does on the Linux >> systems, but it can fall back to flock if fcntl isn't >> available. > > Note that ext3 effectively does the same thing as ZFS on fsync() - > because > the journal layer is block based and does no know which block belongs > to which file, the entire journal must be applied to the filesystem to > achieve the expected fsync() symantics (at least, with data=ordered, > it does). > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ > ---- > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ > Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
