LARGE single-system Cyrus installs?

[Michael R. Gettes]

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