On 2011-07-07, at 6:09 PM, Amir Goldstein wrote:
> On Thu, Jul 7, 2011 at 11:19 PM, Allison Henderson
> <achender@xxxxxxxxxxxxxxxxxx> wrote:
>>
>> Ah, ok then. Yes, part of the requirements was to make secure delete work
>> for partial truncates, punch hole, and also indexed files. So that will
>> save me some time if I can get the migrate routines work. Thx for the
>> pointers all!
>
> I realized that there is a basic flaw in the concept of deferred-secure-delete.
> From a security point of view, after a crash during a secure-delete,
> if the file is not there, all its data should have been wiped.
> Orphan cleanup on the next mount may be done on a system that
> doesn't respect secure delete.
> So for real security, the unlink/truncate command cannot return before
> all data is wiped.
I don't necessarily agree. People who are using secure delete don't
necessarily want their performance to go into the toilet, which is what
would happen if each unlink/zero happened sequentially. It is far more
efficient to submit a large batch of unlink/zero operations and then do
an sync() or fsync() at the end. This allows multiple journal operations
to be coalesced (e.g. unlinks from directory) and block zero requests to
be merged.
> The unlink/truncate metadata changes must not even be committed
> before all data is wiped (or at least part of the data with partial truncate).
That depends on the user, I think. If someone does "rm -r {dir}" it may
be better that the files are removed from the namespace more quickly, and
secure deleted (in a batch) more quickly, than having "rm" wait for each
file to be unlinked and maybe leave files in the namespace that didn't
even get a chance to be unlinked.
Cheers, Andreas
--
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
