So let me try and describe this further:

- Each DDR/DDVE runs a single instance of the DDFS file system

- When created DDFS will contain 1 mtree (/data/col1/backup)

- You can create additional mtrees using the 'mtree create' command

- You can delete mtrees (and all data they contain) with the 'mtree delete' command (the mtree is not physically removed until the next clean is run)

- Additional mtrees are normally created/used to divide logical data sets being written to the DDR - for example:

Each VTL pool will be a separate mtree

Each DDBoost logical storage unit (LSU) will be a separate mtree

Each Avamar grid writing to the DDR will have its own mtree

- Basically each individual application tends to use its own mtree to provide logical data separation

- Note that there is no physical separation of data between mtrees - data written to one mtree still de-duplicates against data in all other mtrees - mtrees offer logical separation only

- The advantage of using multiple mtrees is that:

It makes the DDR easier to administer - you immediately know what type of data/backups are in each mtree and you can see the amount of data written and its de-dupe rate for each individual mtree

Mtrees can be individually replicated - for example this means you can replicate data in /data/col1/mtree1 to destination DDR 1, data in /data/col1/mtree2 to destination DDR 2, and not replicate data in /data/col1/mtree3 at all

Point in time snapshots and so on are created against an mtree and not the whole file system

You can enable/use features such as retention lock against a single or subset of mtrees

If using extended retention (not applicable to DDVE) you can set different migration policies against different mtrees

and so on

- The number of individual mtrees supported on a DDR depends on platform type - as of 5.7 DDVE supports 100 mtrees, i.e.:

# mtree create /data/col1/newmtree

**** Maximum number of MTrees reached.

From BASH mode we can see that this is because 100 mtrees already exist (note that BASH mode is not accessible to customers):

!!!! DDVE_57_JF YOUR DATA IS IN DANGER !!!! # ddsh -a mtree list | grep /data/col1 | wc -l

100

- Within each mtree you can still create subdirectories:

# find /data/col1/testmtree1 -type d

/data/col1/testmtree1

/data/col1/testmtree1/directory1

/data/col1/testmtree1/directory2

/data/col1/testmtree1/directory3

/data/col1/testmtree1/directory4

/data/col1/testmtree1/directory5

#

- CIFS shares/NFS exports can be created against an mtree OR a subdirectory of an mtree - for example creating an NFS export against an mtree:

# nfs add /data/col1/testmtree1 DDVE_57_JF.localdomain

NFS export for "/data/col1/testmtree1" added.

And creating against a subdirectory in an mtree:

# ddsh -a nfs add /data/col1/testmtree1/directory3 DDVE_57_JF.localdomain

NFS export for "/data/col1/testmtree1/directory3" added.

DDRs support many more than 100 CIFS shares/NFS exports (however I do not have the exact number to hand)

- It is not necessary to create a separate mtree for each CIFS/NFS share

- In normal usage where mtrees are used to logically separate backup/data type it is common to see a hand full of mtrees however unless the DDR is a large/complex system it is very unusual to see them hitting their limit of configured mtrees

I hope this helps.