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 :-)
Cheers,
-g
On Dec 15, 2011 10:59 AM, "Philip Martin" <philip.martin_at_wandisco.com>
wrote:
> 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