1

I’ve got 3 portable hard drives one is 160GB, the other two are 500GB. I want to write zeros to them using Linux and dd. I found this command: 

dd if=/dev/zero of=/dev/sda bs=?

How for the block size, what is the ideal block size for my 3 portable hard drives? (Note: I placed the ? at the end of the command.)

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
Charles Whitfield
  • 21
  • 3

2 Answers2

1

For the bs= value, I would recommend setting 1024 like this:

dd if=/dev/zero of=/dev/sda bs=1024

But if you are paranoid about data recovery—and want to do something “stronger” than just write zeros—you could use /dev/urandom instead like this:

dd if=/dev/urandom of=/dev/sda bs=1024

An alternative way to wipe a drive.

But personally, I don’t like to use dd for a task like this. Instead I use a slight variant where I format the drive—and repartitioning if it needs to be repartitioned—and then run the following command. Note that while some might consider this method as supposedly being “inefficient,” you really have to be extremely distrusting of the way partitions and file systems work to believe this method is not a viable alternate method:

cat /dev/zero >> /path/to/mounted/drive/junk_file &

Or this variant using the /dev/urandom device as explained above dd example:

cat /dev/urandom >> /path/to/mounted/drive/junk_file &

Just change /path/to/mounted/drive/ to the actual path of the mounted drive. What that does is create a file called junk_file on the filesystem and do it as a background process with the & appended to the end.

The nice thing about an operation like this is you can stop it and resume it later. Meaning it’s just a file filled with zeros or urandom junk. So let’s say you need to shut down the machine or disconnect the drive. Just do that. And then run that same command again and let it continue where it started. This is useful when wiping data from really large drives that might take hours to complete.

For more details on these—and other—secure device/file deletion methods, check out this page on the ArchWiki. The tips are useful for pretty much any Linux/Unix—even Mac OS X—system and not just ArchLinux.

Speed of the data wiping operation.

As for speed, the overall speed of this type of operation can be estimated by how long it would take your system to copy a 160GB or 500GB file to that same drive. Since writing a file like this is really the data equivalent of “copying” a file; just in this case a file is being created.

FWIW, /dev/urandom will take longer to do it’s thing than /dev/zero—because /dev/urandom is actually generating randomized data—so keep that in mind if time is a factor.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
  • How long would this take on my my 160GB drive? – Charles Whitfield Sep 23 '15 at 17:28
  • Asuming you have USB 2.0, then the writing speed will be around 25-30MB/s. This gives you ~100 minutes for the 160GB drive and ~5.5 hours for each of the 500GB disks. Bottom line: USB 2.0 sucks, USB 3.0 rocks. – alesc Sep 23 '15 at 17:35
  • @alesc - Thanks my good man. I'm using USB 2.0, but it doesn't bother me how slow it is. – Charles Whitfield Sep 23 '15 at 17:42
  • @CharlesWhitfield Good point. It all depends on drive speed, connection speed and all of the typical copy-speed factors. I have updated my answer to explain that as well as show you another way to do a wipe if time is a factor and you want to stop/resume the process later on. – Giacomo1968 Sep 23 '15 at 17:42
  • Or you could use `shred /dev/sda`... – ThoriumBR Sep 23 '15 at 18:06
  • 1
    512 bytes is extremely wastefully slow. You'll incur huge overhead. Go for at least `bs=1M` or you'll be twiddling your thumbs for ages. As for recommending to source data from `/dev/random`, that is a *terrible* idea; [`/dev/random` is for long-term-use crypto keys and similar, not for bulk data!](https://en.wikipedia.org/wiki//dev/random). If you want a lot of strong random data, you need to use `/dev/urandom` instead. – CBHacking Sep 23 '15 at 18:37
  • @CBHacking Fair on both counts. Adjusted as per your suggestions. – Giacomo1968 Sep 23 '15 at 18:49
  • A **dd** command applied to the whole drive will perform a systematic write to ***every*** sector of the drive. Your alternative method of re-partitioning and writing to a "junk_file" cannot guarantee that every sector of the drive is re-written. Therefore your alternative is an inferior method for wiping the drive. – sawdust Sep 23 '15 at 19:55
0

I wrote this as a comment, but I’m going to put it as an answer too for visibility.

For the dd block size, you want a big enough buffer that the program isn't just constantly issuing system calls for trivial amounts of I/O. Having copied a lot of disks using dd, I recommend at least bs=1M, or even something like 16M. If your disk size isn't an exact multiple of your block size then you'll leave a tiny bit of un-overwritten data at the end; it's a safe bet there's nothing there at all but if you want to be paranoid you could manually get that last bit.

Using a small block size (with /dev/zero or any other source) will slow you down, but that's nothing compared to the slowdown you'd get from using a blocking data source like /dev/random, which is what the accepted answer suggests at the time of writing. The purpose of /dev/random is to generate maximum-entropy data, not to generate lots of data. It's not just that it’s slow, but that it draws from an entropy pool of limited size, and the pool doesn't refill very quickly(especially if you aren't doing anything else with the system).

When the pool runs out, reading from /dev/random will block, refusing to supply any more data until the pool refills. You use /dev/random for things like long-term cryptographic keys, not for bulk data. Trying to pull half a terabyte from /dev/random is an absolutely terrible idea. If you want a lot of high-entropy data, you need to use /dev/urandom instead. It uses pseudo-random generators to stretch the entropy pool to an arbitrary size, giving up some entropy in exchange for making sure that a read on it will always succeed in reasonable time.

Community
  • 1
CBHacking
  • 6,119
  • 2
  • 21
  • 34
  • FWIW, [I accepted your comment and criticism](http://superuser.com/questions/977219/wiping-portable-hard-drive-with-dd-in-linux#comment1341865_977223) and [adjusted my answer accordingly 7 minutes before](http://superuser.com/revisions/977223/7) this answer was posted. Additionally, the suggestion of using a random data source came from me, not the original poster. Just adding some perspective to this. – Giacomo1968 Sep 23 '15 at 19:02
  • @JakeGould: CBHacking could have started working on this answer right after posting the comment and not viewed updates until posting this. At this point, though, there is no mention of /dev/random except here, so the gist of this answer is tangential to the question. The first half of the answer is well covered in the duplicate question (which wasn't a duplicate at posting time). (cont'd) – fixer1234 Sep 23 '15 at 19:59
  • 1
    (cont'd) The last half is interesting and possibly useful information, but now not in a useful place because nobody will find it except accidentally. CBHacking, suggestion: post a new question about /dev/random vs. /dev/urandom and self-answer with the relevant portion of this answer (and just delete this answer from here). – fixer1234 Sep 23 '15 at 20:00
  • 1
    @fixer1234: OK, might do that. Yeah, sorry, I didn't see the updated answer until after I'd posted. – CBHacking Sep 23 '15 at 20:06
  • @fixer1234 Very good idea on explaining the difference between `/dev/random` and `/dev/urandom`. Perfect way to get focus on that issue and will reach a larger, it more focused audience. – Giacomo1968 Sep 23 '15 at 20:08