>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
