On 07/04/2011 11:19 AM, Andreas Dilger wrote:
On 2011-07-04, at 11:44 AM, Amir Goldstein wrote:
On Mon, Jul 4, 2011 at 8:19 PM, Allison Henderson
<achender@xxxxxxxxxxxxxxxxxx> wrote:
Thx all for the reviews! It sounds like the zero out code is in the right
spot then. We are thinking about adding an optimization too, where we use
use secure discard instead of the sb_issue_zeroout, but only if the device
supports it. I was thinking about putting that code some where in the
commit call back because that is where the existing discard code is, but
maybe that's not such a good place to put it then? What does everyone
think? Thx!
I already stated my opinion about the need for 2-phase secure delete.
If you have to choose between security (zeroout pre commit) and the
atomicity of the unlink() command (zeroout post commit), then it's
a question of policy.
Is there any other FS (or OS) that implements secure delete?
Perhaps we could follow its semantics.
One thing we did ages ago, before extent-mapped files made unlink so
fast, was to move the blocks from unlinked files and truncated-to-zero
files to a delete queue in the main transaction, and then do the unlink
via a separate thread.
This facility could be resurrected (a version of the patch was posted to
linux-ext4 at http://www.spinics.net/lists/linux-ext4/msg06178.html) to
do the block zeroing/discard in the context of the unlink thread. It
could be structured so that sync/fsync on the file waits for background
zeroing to complete, so that apps doing secure delete + fsync will be
sure that the file is safely erased. The fsync would be needed for this
in any case, otherwise even an inline async zero-fill could fail if the
system crashes before the blocks are actually flushed to disk.
Cheers, Andreas
Oh alrighty, I will look into that then. Thx all for your input! :)
Allison
--
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
