Re: [PATCH] Add wipename option to shred

[Joseph D. Wagner]

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

Joseph D. Wagner