Hi Robert,

Answers are embedded below.


Thank you,

Del

----------------------------------------------------


"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 12/09/2015 
01:17:57 AM:

> From: Robert Ouzen <rouzen AT UNIV.HAIFA.AC DOT IL>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 12/09/2015 01:52 AM
> Subject: Directory Container
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 
> Hello all,
> 
> I define a new storage pool with type=directory container , new 
> feature in 7.1.3.
> 
> I wonder now how.
> 
> 
> Þ     The equivalent command of Q MOUNT  (to view volumes mounted 
> during a backup / restore).
> 
> The only thing I found is Q CONTAINER * STG=pool_name  , give me the
> containers  which belong to a specific stg

Not applicable to container pools.  Because the container files themselves 
are files in the filesystem, there is no notion or "construct" for a mount 
point.  Read access to the containers is managed via normal read semantics 
to a "file" as provided by the filesystem.  And the server manages the 
'write' behaviors so that things behave correctly with multiple 
sessions/writers in-flight at a given time.


> 
> 
> 
> Þ     Or the equivalent command of Q NODEDATA  nodename for nodename
> on stg container ?

Not applicable to container pools.  The Q NODEDATA provided visibility to 
data placement on "volumes" in order to help with understanding what 
volumes would be needed at the time of restore or how well collocation is 
working.  Container pools are built and optimized for deduplicated data - 
namely chunks (or extents as we reference in the documentation).  As such, 
we would expect the data for a given client node to be distributed across 
many containers.  If the Q NODEDATA is of interest in planning for 
restore, this is not needed for container based pools as access to the 
chunks is simply needed and those chunks can be throughout the pool.  
Also, collocation does not apply for container pools - again because data 
is managed at the level of chunks which are expected (or at least likely 
to) span use by many different nodes.


> 
> 
> Regards Robert
>