> So, when do you folks get to figuring that a given filespace is unwieldy
from
> a backup perspective?  I've got several which are ~10M files which I'm
> seriously considering chopping up (virtualmountpoint-wise) just because they
> are a pain to manage.
>
> I watched a dsmc process grow to 960 MB in core downloading the database for
> one of these, and then watching the log scroll ... stutter ... by was really
> painful.
>
> .. so what sounds "big" to you, and in what units do you think of it?

I tend to think of anything over three million files as big, but that
is based on experience with just two cases. We have a client with a bit
over three million files that was chronically troublesome until it went
through a major hardware upgrade. We have a client with over nine
million files that remains chronically troublesome.

Unfortunately, neither of these is a good prospect for the
virtualmountpoint option. In the first case, nearly all of the files
are descendents of a single directory. This directory has several
hundred subdirectories. The application is designed so that each of
these has about the same number of descendents. In the second case,
nearly all of the files are descendents of a single directory with
a few thousand subdirectories. The number of descendents per
subdirectory varies widely, but no one subdirectory accounts for even
one percent of the total file population.

You mention the pain of watching the log scroll. The 'quiet' option,
which eliminates most log output, can result in a significant
performance improvement for clients with large numbers of files.