Creating volumes equal to total available space of aggregate

[StorageNob]

Hello,

Doing some assurance testing in our lab. We have an AFF A700 system.

I do an aggr show command, there is a bunch of aggregate related output. I won't show here as it's a lot. 

What I'm concerned with is the "avalable space" field. On our lab unit it has roughly 32TBs of space on the aggregate.

What I'm trying to do is convert the units to Bytes and then divide the number by 4. Then, I use that number ot create 4 identically sized volumes.

When I get to the 4th volume it fails. For some reason it says I need to size my volume 1 TB (approx) smaller than the previous 3.

What's going on here? I get rounding errors and division but this can't be explained by over 1 TB difference. I want to test writing data to all available space. Is this even possible?

How can I guarantee to my customers that when I cryptographically erase their data there is no residual data remaining? If I can't write to all avialalbe space, I don't see how it is provable.

Thanks

[SpindleNinja]

Couple things.  

You don't want to get an aggr past 95% generally,  let alone 100%.   

If you're just looking at 32TB converted to b,  I don't think you will get an accurate value.  

But there are better ways to securlty store and erase client/customer data.  

1) . Volume or aggr level enctyption - https://library.netapp.com/ecm/ecm_download_file/ECMLP2572742 

2).  disk sanitize. -> . https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-psmg%2FGUID-BE1AF56B-40DD-4C42-99D6-76EEC9225DC5.html 

[StorageNob]

Thanks for the reply. I get what you're saying but I need to verify in my own lab that when I cryptographically erase a volume there is no residual data.

For this test, I am not concerned with performance, I'm concerned with data assurance and being able to guarantee to my customer that when I cryptographically erase a volume there is no residual data.

If I cannot perform a read operation on every byte of the data within the aggregate, how can I say this with any confidence?

[SpindleNinja]

Lets look at NVE.   When an NVE volume is deleted the key is deleted with it.   The data is gone.   

Read a bit more about NVE here: 

 https://kb.netapp.com/app/answers/answer_view/a_id/1086920/~/faq%3A-netapp-volume-encryption-ontap-9.5- 

The encryption power guide is also a good read.  

[StorageNob]

Firstly,

Unless you use the -force delete flag it's not immediately deleted. So that statement isn't entirely accurate.

Second, 

Where is the procedure to validate the keys are no longer being stored in Cache? 

There is this command:

::*>security key-manager query -node <node name>

But is that querying the exact database or location of the key that the node is using for encrypted read/write operations?

None of this explained in any detail. I also still don't understand where the data buffer comes from that doesn't allow me to stretch volumes out to the total available size of the aggregate. This test shouldn't be difficult and really easy to prove except the avaialble space calculations don't seem consistent.

I can show the available space on the aggregate, create an 8TB volume, show the available space on the aggregate. Then Delete the volume and show the available space on the aggregate and the number is significantly different than when I did the first show command. That alone makes me think there must be residual data somewhere.

[SpindleNinja]

The volume and key are put in the recovery queue as an accidental deletion feature.  If you need it gone at that very moment,  yes run -force.     Or you can mod your vserver/SVM to have 0 retention.    The keys are stored within the wafl meta-data which isn't accessible to the user and is deleted along with the volume.    

Starting in 9.4 you can also have the ability to "shred" a single file if needed.  NVE secure purge is GDPR compliant. 

Couple other points:  

This command will give you the side in kb count of the aggr.   "run -node <node> -command df -A"  

Using thin volumes you can go way over the size of the actual aggr.  

Keep in mind there is ways time to clean up the data that is deleted.   

There's always WAFL metadata (which includes more than keys)  hanging around an aggr, so you'll never see 0.  

Run through the encryption/security features of ONTAP with your SE. https://www.netapp.com/us/media/ds-3846.pdf