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.mar...@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 >
