Some quick numbers with my (limited) testing:
All seven of our repositories shrank by 40% to 70% -- that is comparing
freshly 'svnadmin load'ed bdb 4.2.52 (auto log removal on) to fsfs. We
have some large branches, but very few. The repo dump file sizes range
from 50MB to 2GB. The 2GB dump file is 1GB after loading in bdb and
380MB in fsfs.
All seven loaded approximately 3x faster into fsfs vs bdb (with
txn_nosync on). Watching I/O counts, it looks like bdb does about 5x
the reading and 10x the writing that fsfs does during a load.
I found that the hanging problem I'm seeing while loading our largest
repository does not occur under Linux. On Win32, it is blocking at the
same place every time on a ReadFile for one byte. I haven't had time to
dig very deep, but the call stack is below. I'll be out of town and
offline for the week soon, so I may not be able to look at this more
until next week.
DJ
Call stack:
7ffe0304()
ntdll.dll!_ZwReadFile@36
KERNEL32.DLL!_ReadFile@20
libapr.dll!read_with_timeout
libapr.dll!apr_file_read
libapr.dll!apr_file_getc
svnadmin.exe!svn_io_file_getc
svnadmin.exe!svn_io_read_length_line
svnadmin.exe!read_header_block
svnadmin.exe!svn_fs_fs__get_node_revision
svnadmin.exe!get_node_revision
svnadmin.exe!svn_fs_fs__dag_get_node
svnadmin.exe!svn_fs_fs__dag_clone_child
svnadmin.exe!make_path_mutable
svnadmin.exe!apply_text
svnadmin.exe!fs_apply_text
svnadmin.exe!svn_fs_apply_text
svnadmin.exe!set_fulltext
svnadmin.exe!parse_text_block
svnadmin.exe!svn_repos_parse_dumpstream2
svnadmin.exe!svn_repos_load_fs
svnadmin.exe!subcommand_load
svnadmin.exe!main
svnadmin.exe!mainCRTStartup
KERNEL32.DLL!_BaseProcessStart@4
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 26 08:05:44 2004