[ 
https://issues.apache.org/jira/browse/HDFS-11357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851958#comment-15851958
 ] 

Plamen Jeliazkov commented on HDFS-11357:
-----------------------------------------

Current patch seems to affect entire DataNode(s).

Would you be accepting of introducing this on a per-file basis rather than 
per-DataNode? 
HDFS At-Rest Encryption allows for this in the form of per-directory 
(Encryption Zones), for example.

It would mean more work but I could see it being more useful as maybe not all 
the data on the cluster needs to be deleted securely, which could save 
potential device wear.
This would certainly require changes to delete() API though. Thoughts?


> Secure Delete
> -------------
>
>                 Key: HDFS-11357
>                 URL: https://issues.apache.org/jira/browse/HDFS-11357
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>            Priority: Minor
>         Attachments: 0001-HDFS-secure-delete.patch, HDFS-11357.patch
>
>
> Occasionally for compliance or other legal/process reasons it is necessary to 
> attest that data has been deleted in such a way that it cannot be retrieved 
> even through low level forensics (for some reasonable definition of this that 
> typically excludes the resources a state actor can bring to data recovery). 
> HDFS at-rest encryption offers one way to achieve this, if the data keying 
> strategy is highly granular. One simply "forgets" a key corresponding to a 
> given set of files and the data becomes irretrievable. However if HDFS 
> at-rest encryption is not enabled or a fine grained keying strategy is not 
> possible, another simple strategy can be employed. 
> The objective is to ensure once a block is deleted no trace of the data 
> within the block exists on disk in unallocated regions, for all blocks, 
> providing assurance deleted data cannot be recovered at any time through 
> reasonable effort even with low level access. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to