Cifs namespace design question

[stanleyj42]

We just recently moved to cdot from 7mode and Im going through recreating our cifs shares on the newer system.   For some reason Im having trouble wrapping myself around this namespace and junction path concept. Guess i just need it dumbed down for me because im just not getting it even though it seems so simple.

In our current cifs environment I have 2 large volumes with 4 shares inside of them.  easy peasy.

With this namespace setup how do i go about doing something similar?  It appears that I will need to setup a volume for every share and then either mount at the root level or i can nest underneath a junction point.

Is there any point in nesting other than orginization of the namespaces?  Seems like creating a volume just for the ability of a junction point is a waste of space. 

Sorry if this is rediculous.  I just know once i recreate these and they go live i wont be able to change again and I want to make sure I understand this and have it setup correctly

[robinpeter]

if you know Microsoft DFS, namespace consupt is very similar to it. (but it only inside a cluster for one vserver)

You have a volume called volA you can mount them under any path eg:- /departmentA

NAS Clients will never know /departmentA is called volA (they see only departmentA)

Otfourse this is not the only reason namespace exists.

For example, if you want to create a directory structure like the above picture

You can create those volume and mount each volume using the appropriate juncation-path.

And you can share just the top level directory as one share.

The advantage here is you have the flexibilty of netapp flexvol for each one of them.

And it could be in different aggr and different nodes. there for the load on the share will

be more managable for the storge admin.

There is lot more to namespace.. to understand everything I recommend you attend 

a NCDA training or read a lot of documentation.

[SeanHatfield]

You can build it out just like you did in 7mode, or you can make 4 volumes and share them out individually.  Its really up to you.  If you have clients coming in at the volume level today, then you probably will want to maintain the directory structure, either by mimicking your existing volume structure, or using the namespace capabilities and breaking them our into different volumes.  The advantage to splitting them up is you can move them around individually, snapshot them individually, or replicate/vault them individually.  You have more granularity from a data management perspective, if that's important or relevant in your use case.  If its not, then keep it simple.