How secure WAFL really is?

[JFM]

Hi, 

My question may sound like I'm a newbie, but I'll ask it anyway. 

Suppose a 100 GB thin Flexvol sits on an aggregate to serve as an iSCSI volume (VolumeA). 10% of this volume is occupied with user files and snapshots. A sysadmin deletes the volume. The next day, another volume is created on the same aggregate (VolumeB) and presented as an iSCSI LUN to a new Linux server. A clever Linux guy wants to peek a the volume at the first few blocks of the LUN using DD or some other similar techniques. 

What are the chances that OnTap will return a block that was previously used by the first volume that was deleted?

(suppose there is no encryption in use in that system). 

Thank you for educating me!

[hmoubara]

Hello,

Please check the kb below, hopefully should answer your question:

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_does_WAFL_and_striping_distribute_data_among_disks%3F

Thanks 

[JFM]

Well, it is certainly interesting but it's hard for me to deduce a definitive answer from it. 

[aladd]

Adding to this information, for a LUN to be accessible, mapping has to exist within ONTAP. by deleting the volume containing the LUN, the mapping is removed as well.

logical block and physical block allocation when attempting to read the  same would be affected as well. No access would be available to the deleted volume.

[ttran · Accepted solution]

Hello @JFM ,

The scenario you are concerned about cannot exist as there are multiple checks and balances in place to ensure data integrity and if data integrity is ever compromised, the default bahavior will be to induce a PANIC to avoid/prevent any data inconsistencies. Even in a scenario where bits are flipped due to failing physical components, the previously used block won't pass checksum verification resulting in RAID to recalculate the intended payload, respond to the client, then attempt to re-write to the misbehaving block, and if that fails then the block will be marked bad. Furthermore, if RAID can't correct the block and the block is what's considered "User Data", i.e. any data that lives within a LUN, then the entire file will become inaccessible from the host side and will require manual delete and recreate from the host to rectify the issue. The reason being the host OS controls the filesystem and the individual files that live within a LUN. Lastly, as previously mentioned ONTAP will PANIC to pass control over to the HA Partner, as it is highly unlikely both controllers in a HA pair will exhibit the same bit flipping issue.

Adding encryption will add another layer of checks and balances.

Regards,

Team NetApp