I'd actually argue that as long as you don't run out of address space in
your client processes, disabling memoryefficientbackup is actually a
win. At least for NFS, there's a reasonable degree of parallelism
between data and metadata operations.

With memoryefficientbackup enabled, TSM walks a directory, finds files
that are changed, and sends them to the TSM server, in that order.
Without memoryefficientbackup, you can have scout threads finding
directories and files to process, while you have reader threads that are
actually sending data to the TSM server. We've found our throughput to
be much higher with memoryefficientbackup disabled than enabled.

NB: This is with RHEL/NFS, not Windows/CIFS.

On 08/16/13 10:04, Allen S. Rout wrote:

If you're not doing Memoryefficientbackup, then you want to:  for those
big spaces, simply getting the map into core can be a challenge.

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine