[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add wipename option to shred

From: Joseph D. Wagner
Subject: Re: [PATCH] Add wipename option to shred
Date: Thu, 13 Jun 2013 09:13:31 -0700
User-agent: Roundcube Webmail/0.8.6

On 06/13/2013 8:35 am, Pádraig Brady wrote:

On 06/13/2013 12:51 AM, Joseph D. Wagner wrote:

## perchar ##
real    678m33.468s
user    0m9.450s
sys    3m20.001s

## once ##
real    151m54.655s
user    0m3.336s
sys    0m32.357s

## none ##
real    107m34.307s
user    0m2.637s
sys    0m21.825s

perchar: 11 hours 18 minutes 33.468 seconds
once: 2 hours 31 minutes 54.655 seconds
 * a 346% improvement over perchar
none: 1 hour 47 minutes 34.307 seconds
 * a 530% improvement over perchar
 * a 41% improvement over once

Whoa, so this creates 23s CPU work
but waits for 1 hour 47 mins on the sync!
What file system and backing device are you using here
as a matter of interest?

ext4 data=ordered (default) + 7200 SATA

Just to be clear, the times also include shredding the data part of the files.

For my test I used 16 character file names and 100,000 files each 4k in size,
which comes to:
perchar: (1 data fsync + 16 name fsync) * 100,000 files = 1,700,000 fsync
once: (1 data fsync + 1 name fsync) * 100,000 files = 200,000 fsync
none: (1 data fsync + 0 name fsync) * 100,000 files = 100,000 fsync

I included the exact script I used to generate those statistics in a previous email. Feel free to replicate my experiment on your own equipment, using my
patched version of shred of course.

Alternatively, if you still have reservations about adopting my patch,
would you be more open to a --no-wipename option?  This would be the
equivalent of my proposed --wipename=none.  It would not imply any
additional security; to the contrary, it implies less security. Yet, it
would still give me the optional performance boost I am trying to

Joseph D. Wagner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]