Jim Meyering wrote: ... > Odd... no difference in CPU time or syscall counts. > > I wonder if the SSD is doing something special with blocks of all zeros, > which is reminiscent of The Reg's article: > http://www.theregister.co.uk/2011/01/14/ocz_and_ddrdrive_performance_row/
I've redone the doc change accordingly: >From 0f9cf6b545aa07d552538735182007ae240d6071 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[email protected]> Date: Mon, 17 Jan 2011 11:32:35 +0100 Subject: [PATCH] doc: show how to shred more efficiently * doc/coreutils.texi (shred invocation): Give an example showing how to invoke shred in single-pass mode, and warn that -n0 --zero may be inadequate. --- doc/coreutils.texi | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/doc/coreutils.texi b/doc/coreutils.texi index 9c3e2ed..8a1b3b6 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -8892,6 +8892,20 @@ shred invocation shred --verbose /dev/sda5 @end example +On modern disks, a single pass should be adequate, +and it will take one third the time of the default three-pass approach. + +@example +# 1 pass, write pseudo-random data; 3x faster than the default +shred --verbose -n1 /dev/sda5 +@end example + +To be on the safe side, use at least one pass that overwrites using +pseudo-random data. I.e., don't be tempted to use @samp{-n0 --zero}, +in case some disk controller optimizes the process of writing blocks +of all zeros, and thereby does not clear all bytes in a block. +Some SSDs may do just that. + A @var{file} of @samp{-} denotes standard output. The intended use of this is to shred a removed temporary file. For example: -- 1.7.3.5
