[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS nosync

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 15 Dec 2011 13:04:04 -0500

Couldn't we just make that an option for loading, but not provide such a
feature for normal operation? That seems safer to me, and solves the actual
use case.

+1 on the flag name :-)

On Dec 15, 2011 10:59 AM, "Philip Martin" <philip.martin_at_wandisco.com>

> From a discussion on IRC:
> A BDB repository allows the admin to set DB_TXN_NOSYNC in the DBD
> configuration file, this allows the admin to trade performance for
> robustness. We could do something similar in FSFS. When loading a
> dumpfile into a FSFS repository I see 13 calls to fsync per revision on
> a Linux box. If we had such a flag in fsfs.conf (Stefan suggests
> "eat-my-data=yes") the code could write all the same data in the same
> order but avoid making any flush calls thus allowing the OS to order
> physical writes for optimum speed.
> Even if not used on a live repository it is useful to have it available
> when doing things such as loading a dumpfile. The admin could set the
> flag when loading a dumpfile into a new repository and clear it once
> happy with the load.
> As far as an implementation goes: the 13 fsync calls per-revision break
> down to 6 in svn_io_file_flush called directly from fs_fs.c, and 7 from
> svn_io_write_unique. So the code would skip the svn_io_file_flush calls
> and to use some new noflush version of svn_io_write_unique.
> Comments?
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Received on 2011-12-15 19:04:42 CET

This is an archived mail posted to the Subversion Dev mailing list.