REUSEDELAY on Container Stg Pools

[ILCattivo]

I have today deleted a couple of Node file spaces from a Container Storage Pool which at the time only had 8GB free in it, according to the OC.

SP v 8.1.2

Stg dirs defined are S:\ & T:\ which combined total nearly 600 GB

The containers within this stg pool are entirely .ncf files i.e All data is encrypted 100% [no dedup or compression]

Here's how the situation looks now. REUSEDELAY setting is '1'



I actually see more than 15 GB at the OS level? So what gives?

This REUSEDELAY setting, I've read that you should never set it to '0' otherwise all data in the container storage pool is deleted...?? Does that still apply to non-deduped data?

Here's a query of the Extentupdates for the storage pool.



Just trying to understand how this part of the product works compared to the old school 'file' device classes. And how I get the OC and PROTECTS stg pool util to match that of the OS?

 

[marclant]

This REUSEDELAY setting, I've read that you should never set it to '0' otherwise all data in the container storage pool is deleted...??

That's not accurate. What a reusedelay of 0 does is after the data is expired or deleted from the a container, the container is available for reuse right away, as opposed to wait for the number of days set by reusedelay to overwrite those blocks.

The reusedelay should ideally be set at the same retention you use for your database backup. So if you keep your DB backup for 5 days, have a reuse delay of 5. This way the empty containers are not overwritten for 5 days. So if you have to restore the DB up to 5 days earlier, the expired/deleted data will still be in the pool.

Does that still apply to non-deduped data?

The reuse delay is not for the data, but for the containers.

 

[ILCattivo]

That's not accurate. What a reusedelay of 0 does is after the data is expired or deleted from the a container, the container is available for reuse right away, as opposed to wait for the number of days set by reusedelay to overwrite those blocks.

The reusedelay should ideally be set at the same retention you use for your database backup. So if you keep your DB backup for 5 days, have a reuse delay of 5. This way the empty containers are not overwritten for 5 days. So if you have to restore the DB up to 5 days earlier, the expired/deleted data will still be in the pool.

The reuse delay is not for the data, but for the containers.

Thanks marclant,

Guess the Tip for Q22 might be in need of reviewing by IBM.

https://www.ibm.com/developerworks/...tory-container storage pools FAQs?section=q22

Transpires that my issue is more related to the OC not accurately updating the stg pool utilization as the util % via the cli appears more representative of what the OS can see. Another bug maybe!?

 

[marclant]

Transpires that my issue is more related to the OC not accurately updating the stg pool utilization as the util % via the cli appears more representative of what the OS can see. Another bug maybe!?

I don't know if it's a bug or not, but I can provide some insight in what happens.

When you issues queries with the CLI, you query the data directly.

The OC however doesn't use the same queries. It runs the status monitor periodically to update the data in separate tables, that's what the OC uses. You can check to see when the last time those stats were updated on the OC instance:
query monitorstatus name=POOLNAME