On 10/07/2011 10:07 AM, Allison Henderson wrote:
On 10/07/2011 08:21 AM, Andreas Dilger wrote:
On 2011-10-07, at 1:10 AM, Allison Henderson<achender@xxxxxxxxxxxxxxxxxx> wrote:
Sorry for the delay in getting this next version out.
I had some tasks to take care of, and now I'm picking up my
secure delete work again. I'm still not quite done yet,
but a lot has changed and I wanted to update people so that
we have an idea of where its going. Currently the patch
deals with data blocks, meta blocks, directory entries,
journal blocks, and also provides an option for secure
deleting with random data instead of just zeros.
I'm also planning on adding some more patches to
deal with inodes and also a mount option that turns
on secure delete by default. Im still not quite done
debugging, but Im just sending it out early to get
some more eyes on it. Feed back appreciated! :)
v3->v4
Added a new file attribute flag EXT4_SECRM_RANDOM_FL
This flag causes the secure delete operations to over write
blocks with random data instead of zeros.
Since inode flags are in short supply, and I suspect users that want this want it for all files, this should probably be a superblock flag?
That is a really good point. The first thing that comes to mind though would be the fact that it is a lot slower when the random flag is on especially for really big files. So that would be one case where I could imagine a user might want the ability to set different options per file. But since the flags are a limited resource, I can see where we may not want to spend it so quickly. I will see if maybe there is some way I can optimize it, but I would like to see more folks weigh in on this topic too.
I've had another suggestion for this come up, so I wanted to put it out
here to see what people think. Instead of a new flag, we could use a
flag that is mutually exclusive like the undelete flag, since a file
that is secure deleted, should not be undeletable. Would this be
something that people would be interested in doing?
New function ext4_secure_delete_lblks added to walk
data blocks and secure delete them before any blocks
are removed.
Meta blocks are secure deleted before they are
released
New function added to identify holes in ind files.
Used by ext4_secure_delete_lblks to skip over holes
during secure delete.
Added another list in the journal structure to track
journal blocks so that they can be secure deleted later.
Added new ext4_secure_delete_jblks that secure deletes
journal blocks that were used to journal the specified
logical blocks
Allison Henderson (7):
ext4: Secure Delete: Add new EXT4_SECRM_RANDOM_FL flag
ext4: Secure Delete: Add ext4_ind_hole_lookup function
ext4: Secure Delete: Add secure delete functions
ext4: Secure Delete: Secure delete file data
ext4: Secure Delete: Secure delete directory entry
ext4: Secure Delete: Secure delete meta data blocks
ext4/jbd2: Secure Delete: Secure delete journal blocks
fs/ext4/ext4.h | 28 +++-
fs/ext4/ext4_extents.h | 2 +
fs/ext4/extents.c | 21 +++-
fs/ext4/indirect.c | 2 +-
fs/ext4/inode.c | 391 ++++++++++++++++++++++++++++++++++++++++++++++++
fs/ext4/mballoc.c | 8 +
fs/ext4/namei.c | 64 +++++++-
fs/jbd2/commit.c | 6 +
fs/jbd2/journal.c | 112 ++++++++++++++
include/linux/jbd2.h | 21 +++
10 files changed, 642 insertions(+), 13 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
