nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Component react.community-search had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, latest, sort, sortType, lookupSort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.

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

Find more posts tagged with

Comments

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.