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 -- 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
