Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I just upgraded from a 2010 13" MBP to a 2011 15" MBP.

When I boot off the Snow Leopard DVD and go into Disk Utility to erase the drive, should I do a simple erase or should I also zero out the drive?

share|improve this question
2  
Keep in mind that zeroing out an SSD is highly unlikely to truly zero out the disk since SSD's have wear-leveling features that avoid touching parts too many times too quickly (so as to prolong the life expectency of the SSD). –  Kerri Shotts Jun 5 '11 at 16:59
add comment

4 Answers

up vote 1 down vote accepted

Zeroing out the drive is typically done for security purposes, but there is also another benefit to zeroing out an SSD - performance. The firmware of an SSD does a lot of complicated tricks to increase disk performance and reliability, but they become less effective the more data the drive has to retain. Since deleting a file or reformatting a disk does not actually turn the bits on the disk back to zero, the drive firmware must still manage that data. If you zero out the drive, you allow the firmware to stop managing all that data and in turn it's able to offer better performance on the data that you have.

share|improve this answer
1  
To a point, yes. However, it won't offer 100% security against data recovery later due to the wear-levelling. –  user479 Jun 5 '11 at 22:13
    
That's basically theoretical. Unless you're actually a spy, you shouldn't worry about it. –  MJeffryes Aug 5 '11 at 23:26
    
I don't believe this answer is 100% true. "Zeroing" an SSD will not increase performance because the firmware on the drive is keeping track of the fact that the value of each block is "0". This is different than the drive un-setting a value at that block. On write, the disk will have to unset the 0-value before setting the new value. Thus, there is no performance benefit -- and in fact, if this is a new drive that isn't filled, it'll actually hurt performance. –  thesmart May 7 '12 at 17:57
add comment

What I've read on this subject is that it doesn't matter so much what the sectors contain (whether it be 1's or 0's) so much as whether or not the device controller knows that the sector has been erased (as alluded to on this ocz forum post.

In this case, the device controller thinks you actually want to store all zeros in all those sections, so it actually doesn't help (it does the opposite of what you want).

Instead you need to use a special utility to inform the controller that everything has been erased. See this thread

Please note: I haven't actually tried any of this stuff myself. I just have been doing research in anticipation of purchasing an SSD for my 2011 MBP.

share|improve this answer
add comment

You want reinstall your old MBP, because want sale it? So zero out.

Want install OS X into the new MBP - don't need zero.

"Zero out" is for the security. see here too. And if you come from the DoD, CIA etc.. ;) and you have classified informations on you notebook - use the multi-pass zero-out. ;)

For those who have heard that there is someone who has seen such a person who knows how wear-leveling works, ;) TAKE IT EASY :)

I show you how wear-leveling works when erasing a whole SSD sector-by-sector. (and not file-by-file).

For the simplicity imagine than your SSD has only 10 sectors, with numbers from 0 up to 9.
Again, for this example we don't need differentiate between static/dynamic wear-leveling, only need to know, than SSD somewhat counting the write-count into each sector on SSD.

The scheme is the following:

sector number -> 0  1  2  3  4  5  6  7  8  9 
my DATA          .  .  .  .  .  .  .  .  .  .
usage count      0  0  0  0  0  0  0  0  0  0 

for the fresh ssd we have usage count "0" for all sectors. (in reality this is not true, but for this example it is ok), and we haven't any data on the SSD.

Ok, after a while of usage of normal usage of SSD we get for example the next:

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          .  .  x  x  .  .  x  .  .  .
usage count      5  6  6  6  5  5  7  6  4  5

so, we have physically occupied sectors# 2,3,6 (so, my data ARE really in these sectors, and does not matter what OS think where they are) and the SSD maintain his usage table. You can see the usage table (bottom row) is nearly leveled. (why is not exactly leveled does not matter for this example, and also we not need discuss how SSH maintain the his free sector table, but need to know, than the SSD's free sectors table has nothing with the OS's free sector table).

So, come erase the whole SDD sector-by-sector. What this mean? The OS will write some data (not always zeroes) into each sector sequentially on SSD.

The OS send a command to SSD "write these zeros onto sector 0". The SSD's wear leveling choose on block with the lowest number of writes and write the zeros into. In our small example this will be sector 8, so we get:

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          .  .  x  x  .  .  x  .  -  .
usage count      5  6  6  6  5  5  7  6  5  5

I draw with '-' the written sector for the erase process. So the OS "think" than got erased the sector 0, but this is not true, because the wear-leveling erased the sector 8.

Next, the OS want erase sector "1". The wear leveling choose the first sector with lowest number of write, so sector 0 in our example.

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  .  x  x  .  .  x  .  -  .
usage count      6  6  6  6  5  5  7  6  5  5

for the sector 2 - got written into sector 4

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  .  x  x  -  .  x  .  -  .
usage count      6  6  6  6  6  5  7  6  5  5

sector 3 -> 5

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  .  x  x  -  -  x  .  -  .
usage count      6  6  6  6  6  6  7  6  5  5

sector 4 -> 8 (AGAIN got a write into sector 8, because it has the first sector with the lowest number of writes)

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  .  x  x  -  -  x  .  -  .
usage count      6  6  6  6  6  6  7  6  6  5

sector 5 -> 9

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  .  x  x  -  -  x  .  -  -
usage count      6  6  6  6  6  6  7  6  6  6

sector 6 -> 0

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  .  x  x  -  -  x  .  -  -
usage count      7  6  6  6  6  6  7  6  6  6

sector 7 -> 1

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  -  x  x  -  -  x  .  -  -
usage count      7  7  6  6  6  6  7  6  6  6

sector 8 -> 2

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  -  -  x  -  -  x  .  -  -
usage count      7  7  7  6  6  6  7  6  6  6

sector 9 -> 3

sector number -> 0  1  2  3  4  5  6  7  8  9 
MY DATA          -  -  -  -  -  -  x  .  -  -
usage count      7  7  7  7  6  6  7  6  6  6

As you can see, after the 1st pass, (the OS think than got erased all sectors) but in the reality sectors 6 and 7 got not touched.

In the next pass, the sector number 6 still not get erased. But in the 3rd pass GOT erased. In the reality it is more complicated, but the base principe is:

  • if you erasing the whole drive sector by sector (and not at filesystem level, so not file-by-file), you will get leveled all sectors on write
  • while you can not ensure, than all your files got erased on 1st pass, on multi-pass you can ensure this, just because of wear-leveling.

Now i show, why some users get confused about the erase. Imagine:

  • we have an empty SSD - all sectors has zero usage count. The SSD has for example 10 sectors.
  • we write one file, what got written into the first sector on SSD because this sector is the first with the usage count 0. So the sector #0 will have usage count 1. (again, this is not true in the reality, because of inode table, or FAT tables at the start of SSD - but for the example is ok)
  • so, the other 9 sectors are free (and has usage count 0). When you rewrite THE FILE 9 times, you physically got writes into the sectors 1-9, so after 9th rewrite your file is STILL IN SSD and possible to recover it. That is because you write only 1 sector at the time (rewriting only the space occupied with the file).
  • in the SSD with 1000 sectors, we can not ensure physical rewriting of the file (with length of 1sector) either in 1000pass erase.

But with the multi-pass erase of the ALL sectors (sector-by-sector) in SSD, you will get cleared all sectors and all sectors will have the same write-count at the end. (and the oldest FILE get erased first).

Just ask, if something is not fully clear.

share|improve this answer
    
Except this doesn't apply to SSDs because of wear-levelling. –  user479 Jun 5 '11 at 22:12
    
I bought the SSD separately and replaced it with the standard hard drive before selling the old MBP. I always do a clean OS X install with a new Mac. –  Ryan Jun 5 '11 at 23:49
    
care the downvoter tell me what is wrong with my reply? –  jm666 Jun 6 '11 at 8:14
add comment

I'm not sure why everyone jumped on the idea that this concerned an SSD...

Still, while I can't speak to Kyle's answer, as Apple's firmware and hardware differ from other SSD's on the market...unless you're paranoid and intend to sell the older unit, I wouldn't bother with it (7 & 35 pass wipes exist because 0 pass is not infallible).

Back on topic, though: It's worth noting that the normal 2010 MBP 13" didn't come with SSD. That said: Erase, re-partition (1 partition, GUID), and reinstall. Enjoy!

share|improve this answer
2  
The subject says SSD, that's why everyone jumped on the idea. –  user479 Jun 5 '11 at 22:12
    
Haha! Thanks. Didn't even catch that. –  David Metcalfe Jun 5 '11 at 22:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.