<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In addition, what is the value of the data? Is it worth the effort to reclaim it? What does it cost you to lose that info to someone nefarious?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>One alternative to copying zeros to the drive is to copy from /dev/urandom (I think its urandom, since random is MUCH slower. If you find it takes HOURS to fill a few megabytes then use the other random device) – that gets you the ‘hard to filter known data’ issue without the 14 hours write times for shredding.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Assuming hiding the data is worth the time, and those who get the computer are even likely to try to recover the data.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>On the BS issue, as George says, it depends entirely upon the drive. On our SSDs I generally use 1MB, since our SSDs do very well on large block sequential writes – which is what you are getting as you make the block size larger. However, there is a limit to the improvement you can get – obviously even if the drive could go faster and faster, you still have memory limitations and so forth. (there are 2 primary LBA sizes for ATA commands. IIRC its 48 bit and 28 bit, but I could have the numbers wrong. In any case, in the smaller addressing range you can send a single ATA command to write 256 LBAs using DMA, so you only get the command decode (and ack/etc) overhead once per 256 LBAs (which each holds 512 bytes, usually). For 48-bit mode, you get to write 65536 (or more, again I forget exact numbers) LBAs with a single command (ABLE TO LEAP 65536 LBAs in a single command!!!! ;-), but that assumes you’ve got enough memory not to send yourself into starvation </span><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> - the point of this rabbit hole I’m in is twofold – one is to note that 256*512 is 128KB, so if your drive only does 28-bit (or whatever the smaller mode is) addressing then you can only do 128k at a time anyway, and two is to point out that a lot of the gain you are getting by going to larger block sizes is to avoid all the command chatter and latency on the SATA (or PATA or whatever) bus. (And, three, is to note that above 256 LBAs your percentage of command vs data gets lower and lower, so you may find you don’t get much gain beyond 128KB anyway – hmm, I feel an experiment coming – thanks George for already writing the code for me! </span><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>Rusty</span><span style='color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> plug-discuss-bounces@lists.phxlinux.org [mailto:plug-discuss-bounces@lists.phxlinux.org] <b>On Behalf Of </b>George Toft<br><b>Sent:</b> Monday, August 19, 2013 7:41 AM<br><b>To:</b> keith smith; Main PLUG discussion list<br><b>Subject:</b> Re: shred vs writing zeros to wipe a drive<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Stephen mentioned one aspect - impact if someone recreates the data. Another is the technical capability of the hard drive recipient and anyone else that gets the drive. Overwriting with 0's (or 1's) creates a regular pattern that can be filtered out to retrieve the remnants of the previous data, which is why the DOD standard is 7 passes. That being said, I've never met anyone who had the technical capability to retrieve data off drives once they've been overwritten.<br><br>As fate would have it, I've developing a CD/USB-bootable image whose sole purpose is DOD-wiping every drive in the system. It's like DBAN (Derek's Boot and Nuke) on steroids.<br><br>As far as bs (block size), in my experience, bs affects the speed of the dd. Too small or too large and the time increases. For the ATA drives I've dealt with, the sweet spot was 32K, but this depends completely on drive type. Clearly YMMV and you might experiment with different values. Wrap the dd command in a for loop and time the execution of the dd command. Create a 1GB test file and then run something like this:<br>dd if=/dev/zero of=/tmp/testfile bs=1024 count=1024000 # close enough<br>while [ $BS -le 134217728 ]; do<br> COUNT=$((1048576000/$BS))<br> echo BS=$BS<br> dd if=/dev/zero of=/tmp/testfile bs=$BS count=$COUNT<br> BS=$(($BS+$BS))<br> echo "-------"<br> done<br><br>When I ran this, I got speeds that varied by up to 50%. Finding the right blocksize can save you several hours.<br><br><o:p></o:p></p><pre>Regards,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>George Toft<o:p></o:p></pre><p class=MsoNormal>On 8/18/2013 8:19 PM, keith smith wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='background:white'><o:p> </o:p></p><div><p class=MsoNormal>Hi All,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I have an old computer that I am giving to a friend so I wanted to wipe the drives in preparation for that.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The master is 250GB<o:p></o:p></p></div><div><p class=MsoNormal>The slave is 1TB.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I read a couple articles that suggested using a rescue disk and the shred utility to take care of this. I also read that shred is not necessary to just write all zero's to the drive.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The rescue disk I am using is DVD disk one of CentOS 6.3.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I ran shred on the fist drive. It took 4.5 hours to run 3 shred passes plus 1 that writes zeros to the entire drive.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Command : shred -zv /dev/sda (this was on the master disk)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Then I ran : dd if=/dev/zero of=/dev/sda bs=16M<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In one of the articles it showed the above command with bs=1M<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Does the size of "bs" matter?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Also what about the argument that shred is overkill?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks!!<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Keith<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='background:white'>------------------------<br>Keith Smith<o:p></o:p></p></div></div><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>---------------------------------------------------<o:p></o:p></pre><pre>PLUG-discuss mailing list - <a href="mailto:PLUG-discuss@lists.phxlinux.org">PLUG-discuss@lists.phxlinux.org</a><o:p></o:p></pre><pre>To subscribe, unsubscribe, or to change your mail settings:<o:p></o:p></pre><pre><a href="http://lists.phxlinux.org/mailman/listinfo/plug-discuss">http://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></body></html>