On Jan 27, 2008 8:43 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> If there was no fallback would you take the performance hit (which is
> huge on your repository) or do the dump/load? Both options are so
> bad, that I was suggesting it might be worth the effort to possibly
> support both options to give a better upgrade path.
If doing a dump-load would give us remarkably better disk usage, ya,
we'd do that. But, AIUI, that's not the case here, is it? That's
only if a hypothetical separate 'node origin cache' were to be
introduced separated from the per-inode one glasser just committed,
right?
> Well, I was suggesting some kind of filesystem format that handles
> lots of small files efficiently. Depending on the format, you might
> not need a lot of disk space to handle it.
We currently use FreeBSD's ufs/ffs - IIRC, the FFS default block size
is 8KB; we *may* consider using FreeBSD 7's zfs implementation for our
new SVN server. (So, at 8KB/inode with currently 1.2 million inodes,
I think that'd be 9GB for what is now a 24GB repository...I just did a
du, so the 24GB overall size is accurate...)
But, having multiple file-systems on one disk isn't efficient (or
reliable), so we try to avoid that. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-27 18:10:28 CET