Time to wipe data/cache!

So a few months ago I was approached by some members of the community who asked me to do a write up on the notorious multiple data wiping that people seem to be doing to their devices. It had become a common thing to have install instructions on ROMs to include phrases such as: Be sure to wipe data/cache at least TWICE.

Well I'm here to tell you all that wiping your data more than once is a waste of your time. If, during an install session, you want to wipe something, you only have to wipe that data ONCE, be it cache, system, etc.

Now because there are those who will swear to the second Sunday of September that they have wiped multiple times and that it has solved all of the world's problems, I will try to explain why multiple wipes are unnecessary.

Think about it. When you select “wipe data/cache” in CWR or any other recovery for that matter, that is a routine run within code. Unless the developer of the recovery has thrown in a random number generator that determines what happens next (none of them do), then the same code routine is run every time you run a wipe.

If every wipe does the same thing, then why would there be a reason to believe you need to do it more than once consecutively? If there is concern that the wiping process “doesn't do the job in one blow”, then that's a software problem that needs to be addressed, but I can assure you, that is not the case. The only way that the execution path could be altered on subsequent wipes would be if there were some sort of randomness to the path selection, and after analyzing the code that is not the case.

Now, there are times when wiping data/cache do not work for various reasons (the recovery installed is faulty, was built wrong, implemented wrong, etc). But here's the thing, when that happens, then that means it wont ever work until it is fixed. It won't magically start working without modification to the recovery.

Regardless, think about what wiping multiple times means. It means that you believe that when you tell your recovery to perform an action, you believe that it MAY OR MAY NOT do it regardless of your request. If that is true, then you may want to re-evaluate whether or not you trust that recovery enough to really be using it.

Edit [2011/06/24]: Under the hood, how CWR formats your partitions

BEWARE! Below I will be describing the code makeup of the format functionality of Clockwork Recovery. Some may find it extremely technical and quite droll, but I felt it needed to be here as justification for my previous claims. I claim no responsibility for anyone who feels that a portion of their life was taken from them that they'll never get back for reading the following writings.

It has been requested of me to show more proof of my aforementioned claims, so I am going to walk through exactly what Clockwork Recovery does when you request to wipe data/cache. Obviously there are other recovery solutions out there, and I cannot speak for them as I do not have the source code for them.

format_volume()

For this section I will be speaking on the global call, format_volume() which is called whenever a volume of any kind is supposed to be formatted. This is called via a function named erase_volume() which is called by the menu options to wipe/format various partitions (such as data and cache).

You can find the calls to erase_volume(), as well as its definition (on approx line 322) in the source code here: recovery.c.

As we can see on line ~335, erase_volume() calls to format_volume() which is defined on line ~286 of roots.c.

The first few lines of code (~287 to ~310) do some checks to make sure the volume we're trying to format is valid and see if we need to call format_unknown_device(). Note that at any point if there is a failure a log message is printed (with the exception of /sd-ext which fails silently as it may or may not exist on any given device).

From there, we look at the next few lines (~312 to ~348), which essentially say “attempt to unmount the device if it's mounted, and then depending on if the volume is of type yaffs2 or ext4, format it accordingly. Note once again that in the event of a failure to perform any of these tasks, an appropriate message is logged.

Finally, if we have not done anything yet, then on the last line of the function (line ~354), we attempt to call format_unknown_device().

So at this point we can see that if something goes wrong during our wipe within this function, we should at the very least see a message of that error. But there were some calls to format_unknown_device() that remain unchecked, so let's see what that does.

format_unknown_device()

format_unknown_device() is defined in extendedcommands.c on line ~422.

On lines ~426 to ~428, there are some lines that essentially check if the device we're trying to erase is a valid flash device, and if so calls erase_raw_partition() on it. At this point there is a series of branches in which, depending on the flash type of your device, it will call a specific erasure method. All of these erasure methods perform similar tasks, namely they write raw blocks to the partition until it is overwritten with a blank slate. The files where this is performed can be found https://github.com/CyanogenMod/android_bootable_recovery/tree/gingerbread/flashutils here, here, and here. I'm not going to dig through there because the same code that's used to wipe the partitions (as per writing), is used for restoring partitions from nandroids. The code would also be quite tedious to dig through and explain here. If there was reason to believe that wiping data/cache on those partitions required several tries to take, then people would also by that turn need to restore nandroids several times to get them to take.

Back to format_unknown_device(). Next up is lines ~429 to ~460, which essentially check if we are formatting /sd-ext, or an ext2 or ext3 partition. In the case of the former, we just make sure that /sd-ext exists for now and continue on if it does. If it doesn't we error out and leave. In the case of ext2 or ext3, we first ensure that the volume isn't mounted and then call the respective format functions. These functions can be found in mmcutils/mmcutils.c, and from glancing at them we can see that they are essentially run by calling off to mke2fs and tune2fs. I am going to assume that those commands don't need to be run more than once for a device to be truly formatted, as that has never been recommended in any Linux distribution that has been released over the years.

So now we're back at format_unknown_device(), lines ~461 to ~480. At this point recovery doesn't know how to truly format the device, so instead it says “mount the volume, then run rm -fr * on it”. This basically means mount the partition and delete everything on it. When it's done it then unmounts the volume again. Some might say that this could fail due to permissions issues, but remember that these format functions run as root, so the system will let them do whatever they want, irregardless of permissions.

Final thoughts

There is one case where you may need to format more than once. That is the case of a partition of some kind being busy, and therefore the format fails at some point. But the thing is, if that were to happen, you would see a visible error indicating that the format failed. Thus I still maintain the opinion that wiping data/cache multiple times just for the sake of doing it is unnecessary.

I hope that shed some light on how the systems work on a lower level, and acted as justification for my previous claims. I am always open to debate; however, and if someone has verifiable proof that my logic is flawed at some point, please point it out to me so that I may correct this post. This post was not intended to be a soapbox but more of an attempt to end a completely unnecessary practice within the Android community.

tl;dr

there's no logical reason for you to wipe your data more than once before attempting an install.

Comments

 
blog/2011-06-05/time_to_wipe_data/cache.txt · Last modified: 2014/05/13 12:36 (external edit)
 

Hosted on Microsoft Azure Powered by PHP Driven by DokuWiki RSS Feed

© 2011 Austen Dicken | cvpcs.org