Related
Hi mates,
When we are flashing a Custom Rom from the CWM, we are normally instructed by the Devs only to do few steps on CWM like “Wipe Data/Factory Data Reset, Wipe Cache etc.. which we simply follow, but most of the people don’t know, including me, what these options and many other options of CWM are really standing for.
When I googled, I could not find a thread which explains about these options in a single thread, so I would like to share with my friends about what I found the Common Options of the CWM here...
Obviously these are commonly applicable for all the devices which are having CWM, but I am always concern about my favorite Galaxy S II.
People who are completely new to Recovery and these options, I suggest them to read this thread first and give a thanks to it's author.
What Is Recovery & Download Mode?
The oder and segregation of the below items in the CWM menu may vary or some of them may be removed in different custom recoveries designed by respective Developer.
CLOCKWORKMODE BASED RECOVERY MENU
1) Reboot Menu :
reboot system now
This one is self-explanatory.
2) Install Menu :
choose zip from (internal/ external) sdcard /
Lets you install any zip file (with any name) from any location on your SD card. The file can be for a ROM, a kernel, an application, a theme or any mod as long as it is in recovery-flashable zip format.
apply /sdcard/update.zip
This one is essentially the same as the ‘apply update from sdcard’ option of the main menu. widely used option for installing a ROM that you have downloaded and copied to your SD card. Entering this option will bring up a screen that will allow you to browse your SD card for the zip file.
apply update from sdcard
This can be used for installation of any official or unofficial update, ROM, kernel, theme etc. that is in a zip format installable from recovery, as long as the file is named update.zip and it has been placed on the root of your SD card (i.e. not in any sub-folder). Selecting this option will bring up a rather annoying confirmation prompt but this has saved us on multiple occasions from a lot of trouble we would have been into due to accidental key presses.
toggle signature verification
Turns the signature verification on and off. When signature verification is on, you will not be able to install any custom ROMs that haven’t been signed by the developers (most custom ROMs aren’t signed). Switching it off skips the signature verification check and proceeds with the installation.
toggle script asserts
Seldom-used option for a vast majority of users. It simply turns script asserts on or off. If you don’t know about these (I don’t), it’s best not to change this option.
3) Wipe Menu
wipe data/factory reset
This option wipes all user data on the device as well as cache. Doing this will leave your phone in the state it was in when you bought it or when any custom ROM was first installed. It will also wipe any sd-ext partition that you might have setup. (see more about sd-ext below under partition)
wipe cache partition
This is a good practice to do this before flashing any ROM. The /cache partition just stores temporary files that are not critical to device operation and can be re-generated easily, this Wipes the cache partition of the device to clear all the data accumulated there over use. This is often used before installing a new ROM, app, kernel or any similar mod via recovery.
Wipe Dalvik Cache
Allows you to wipe the cache for the Dalvik virtual machine. The dalvik cache wipe is quite similar to cache wipe but it stores the post ran java applications. Since Android is JAVA based, it uses the same java virtual machine for compiling. The dalvik cache just stores post-compiled applications in order to speed up the system. Wiping this just forces the system to re-cache those application. It causes no problems but a slight hint of lag on first boot. This is required before most ROM installations and at other occasions too, for fixing some problems.
Wipe Battery Stats
Wipes the saved battery usage statistics and effectively recalibrates the battery. Useful in various scenarios when Android isn’t showing correct battery levels.
4) Nandroid menu
backup and restore Undoubtedly one of the most important features provided by a custom recovery, the backup and restore feature – also known as Nandroid backup – allows you to take a snapshot of your phone’s entire internal memory including all partitions, and save it on the SD card.
Backup
Takes a Nandroid backup, as explained above.
Restore
Lets you restore a previously taken backup. Entering this option presents you with a list of existing backups from the SD card that you can choose from for restoration.
Advanced Restore (new options are available separately to restore from external or internal SDcard in the latest CWM)
This option is similar to the Restore option but once a backup has been selected to be restored, this option allows you to choose what parts of it to restore. You can choose to restore the boot, system, data, cache and sd-ext partitions.
5) Storage menu
mounts and storage
Allows you to perform maintenance tasks on all the internal and external partitions of your android device
mount/unmount /system, /data, /cache, /sdcard, /emmc.
These options let you toggle between mounting or unmounting these respective partitions. Most users don’t need to change these options.
format system, data, cache, sdcard or sd-ext
These let you directly format any of these partitions. Take extreme care with this option as formatting any of these partitions will result in losing all data on them, especially the boot and system partitions. Formatting the system partition will remove your ROM and leave your phone without an operating system while wiping the boot partition may brick your phone unless you restore or flash another one before rebooting your device. See below more explanation about these partitions.
mount USB storage
Lets you enable USB mass storage mode for your SD card right from recovery so that you can connect it to your computer via USB and transfer any files to/from it without having to leave recovery.
6) Advanced
This section contains a few options most users will not require, Here are the options from this section:
Report Error
In case of errors, this feature can be used to save a log of recent ClockworkMod recovery operations on the SD card that you can later report from Android using ROM Manager.
Key Test
Lets you press any of the hardware keys to see if they are properly functioning, and to see their key codes.
Partition SD Card
This option gives you a no-frills way to partition your SD card properly for use with ROMs that support data2ext (a very handy hack for low internal memory devices that enables an /sd-ext partition on the SD card to be used as the internal user data storage i.e. as the /data partition). Once this option is selected, you will be given options to choose the sizes for the /sd-ext partition as well as an optional /swap partition on the SD card, and will then automatically format it for you, leaving the remaining space for normal SD card usage. This option will wipe all data from your SD card so use it with caution!
Fix Permissions
Fixes the file permissions for the internal memory partitions back to default. This is very useful as a fix for several errors and Force-Closes that start appearing after you or an application you installed and provided root access end up messing up the permissions of important files.
PARTITIONS :
The Android uses several partitions to organize files and folders on the device. Each of these partitions has a distinct role in the functionality of the device, but not many Android users know the significance of each partition and its contents. In this guide, we will take you on a tour of Android partitions, what they contain and what can be the possible consequences of modifying their content.
Let’s start with a list of standard internal memory partitions on Android phones and tablets. These are:
• /boot
• /system
• /recovery
• /data
• /cache
• /misc
In addition, there are the SD card partitions.
• /sdcard
• /sd-ext
Note that only /sdcard is found in all Android devices and the rest are present only in select devices. Let’s now take a look at the purpose and contents of each of these partitions.
/boot
This is the partition that enables the phone to boot, as the name suggests. It includes the bootloader and the kernel. Without this partition, the device will simply not be able to boot. Wiping this partition from recovery should only be done if absolutely required and once done, the device must NOT be rebooted before installing a new one, which can be done by installing a ROM that includes a /boot partition.
/system
This partition basically contains the entire operating system, other than the kernel and the bootloader. This includes the Android user interface as well as all the system applications that come pre-installed on the device. Wiping this partition will remove Android from the device without rendering it unbootable, and you will still be able to put the phone into recovery or bootloader mode to install a new ROM.
/recovery
The recovery partition can be considered as an alternative boot partition that lets you boot the device into a recovery console for performing advanced recovery and maintenance operations on it. We have already learnt about this partition and its contents above.
/data
Also called userdata, the data partition contains the user’s data – this is where your contacts, messages, settings and apps that you have installed go. Wiping this partition essentially performs a factory reset on your device, restoring it to the way it was when you first booted it, or the way it was after the last official or custom ROM installation. When you perform a wipe data/factory reset from recovery, it is this partition that you are wiping.
/cache
This is the partition where Android stores frequently accessed data and app components. Wiping the cache doesn’t effect your personal data but simply gets rid of the existing data there, which gets automatically rebuilt as you continue using the device.
/misc
This partition contains miscellaneous system settings in form of on/off switches. These settings may include CID (Carrier or Region ID), USB configuration and certain hardware settings etc. This is an important partition and if it is corrupt or missing, several of the device’s features will will not function normally.
/sdcard
This is not a partition on the internal memory of the device but rather the SD card. In terms of usage, this is your storage space to use as you see fit, to store your media, documents, ROMs etc. on it. Wiping it is perfectly safe as long as you backup all the data you require from it, to your computer first. Though several user-installed apps save their data and settings on the SD card and wiping this partition will make you lose all that data.
On devices with both an internal and an external SD card – devices like the Samsung Galaxy SII – the /sdcard partition is always used to refer to the internal SD card. For the external SD card – if present – an alternative partition is used, which differs from device to device. In case of Samsung Galaxy S series devices, it is /sdcard/External_sd while in many other devices, it is /sdcard2. Unlike /sdcard, no system or app data whatsoever is stored automatically on this external SD card and everything present on it has been added there by the user. You can safely wipe it after backing up any data from it that you need to save.
/sd-ext
This is not a standard Android partition, but has become popular in the custom ROM scene. It is basically an additional partition on your SD card that acts as the /data partition when used with certain ROMs that have special features called APP2SD+ or data2ext enabled. It is especially useful on devices with little internal memory allotted to the /data partition. Thus, users who want to install more programs than the internal memory allows can make this partition and use it with a custom ROM that supports this feature, to get additional storage for installing their apps. Wiping this partition is essentially the same as wiping the /data partition – you lose your contacts, SMS, market apps and settings.
Now whenever we install a ROM or mod that requires we to wipe certain partitions before the installation, we should be in a better position to know what we are losing and what not and thus, we’ll know what to backup and what not.
Best Regards
http://forum.xda-developers.com/showthread.php?t=1134290
Yep. Been done before a long time ago. Tho I do admire your initiative in putting the info together
Stifler69 said:
http://forum.xda-developers.com/showthread.php?t=1134290
Click to expand...
Click to collapse
No Doubt this one should be on the top of this thread,
What a simple and awesome explanation about the Recovery & Download mode, many thanks to pulser_g2
I know, majority of users only need the simple steps and shortcuts, they don’t care what’s happening internally and theoretically, but some are really curious to know…
Many thanks mate....
zaheedahmed said:
No Doubt this one should be on the top of this thread,
What a simple and awesome explanation about the Recovery & Download mode, many thanks to pulser_g2
I know, majority of users only need the simple steps and shortcuts, they don’t care what’s happening internally and theoretically, but some are really curious to know…
Many thanks mate....
Click to expand...
Click to collapse
Nah mate you do what you have to do. It is a good thread and provides good information. Nice work. Just wanted to show you Pulsers thread as well though because he has done something similar to yours long time ago..But anyway good work and if you need any help let me know
Thanks, will save later text in PDF and keep it on PC just to have one more tutorial about things
Awesome write up!! Brilliant!
As you are so knowledgeable about CWM, perhaps I can ask you a question?
When I do a backup, it says that no external SD card was found, so it skipped the external?
When I check under mounts, the only option for the external SD card is to UNmount.... This would suggest that the card is mounted, correct?
So how would I go about backing up the external card too?
Thanks!
Sent from my SGH-I727R using xda premium
Question, if i do nandroid backhp through CWM, i suppose it saves files that i dl such as apps/games, or i need to download later again 600mb+?
Sent by powaaaaah of GT-I9100 Taparatatatalk!
shaggyskunk said:
Awesome write up!! Brilliant!
As you are so knowledgeable about CWM, perhaps I can ask you a question?
When I do a backup, it says that no external SD card was found, so it skipped the external?
When I check under mounts, the only option for the external SD card is to UNmount.... This would suggest that the card is mounted, correct?
So how would I go about backing up the external card too?
Thanks!
Sent from my SGH-I727R using xda premium
Click to expand...
Click to collapse
Thank you for your appreciation,
I would like to express once again as I mentioned in the starting of the thread that this is only a humble effort of the undersigne that I searched for such information and combined at one place here....
As far as I know about your problem of SD card storage, this is a compatibility issiue which varries on one custom recovery to another, also one SD card to another. such issues are fixed by developers in their latest versions of recoveries.
I experienced once the same issue which was resolved when I changed my SD card.
And my current (touch) recovery of Redpill v1.3 allows me to Backup and restore from external SD card with all available options flowlessly.
Thanks
X-Plosiv said:
Question, if i do nandroid backhp through CWM, i suppose it saves files that i dl such as apps/games, or i need to download later again 600mb+?
Sent by powaaaaah of GT-I9100 Taparatatatalk!
Click to expand...
Click to collapse
Between CWM & Titanium, you should not have to download anything.
Sent From my Two Tin Cans & String Device on The Wookie Network
X-Plosiv said:
Question, if i do nandroid backhp through CWM, i suppose it saves files that i dl such as apps/games, or i need to download later again 600mb+?
Sent by powaaaaah of GT-I9100 Taparatatatalk!
Click to expand...
Click to collapse
Of course it backs up all your installed apps and system data along with the ROM, but it do not back up the additional data which is downloaded and stored in User's partition of your SD card by the applications, such data will remain on your SD card untill you format it, available to support your apps when you return to the previous ROM.
awsome eplanation
as above posts say awsome explinationculdnt b clearer now then all
zaheedahmed said:
Of course it backs up all your installed apps and system data along with the ROM, but it do not back up the additional data which is downloaded and stored in User's partition of your SD card by the applications, such data will remain on your SD card untill you format it, available to support your apps when you return to the previous ROM.
Click to expand...
Click to collapse
Yes, but when I do format/wipe all, I guess then it deletes all that is on SD card as well, such as game files and music? If so, I'd rather just copy paste it on my PC, then after doing all wipes and formats, just copy back from PC
Zaheed, you are far too humble! Your post was brilliant, informative & timely.
Sent From my Two Tin Cans & String Device on The Wookie Network
X-Plosiv said:
Yes, but when I do format/wipe all, I guess then it deletes all that is on SD card as well, such as game files and music? If so, I'd rather just copy paste it on my PC, then after doing all wipes and formats, just copy back from PC
Click to expand...
Click to collapse
When you do normal wipes (data/ factory reset, cache, dalvik) before installing/restoring ROM, it won't touch any data which is saved in your SD Card normally, but it is more safer if you back such application data to you PC which normally find in a folder "Android/ Data /xxx" in the root of SDcard
Thanks for info.
I have read a lot on this but am still nor clear whether a wipe data/factory reset includes a full cache wipe. Most rom install instructions tell you to do both, but it seems a wipe cache is redundant if you factory reset.
SimboXXX said:
Thanks for info.
I have read a lot on this but am still nor clear whether a wipe data/factory reset includes a full cache wipe. Most rom install instructions tell you to do both, but it seems a wipe cache is redundant if you factory reset.
Click to expand...
Click to collapse
Yes, you are right, I also understand the same, but the option for merely wiping cache is kept for using in some odd situations, like when we fingered to the ROM and got some error, then we got a no-wipe version of the existing ROM to reflash, such case we need only to wipe cache…. I have got an error recently on CWM when I reflashed my no-wipe Checkrom v6 without wiping anything, then I wiped only cache, problem solved…..
what ever may be the theory, do as the developers directed for their ROM…..NO RISK
shaggyskunk said:
Zaheed, you are far too humble! Your post was brilliant, informative & timely.
Sent From my Two Tin Cans & String Device on The Wookie Network
Click to expand...
Click to collapse
thanks mate...
Thanks for the thread, you can never know too much. On second thoughts, there's probably no danger of that.
What would be really good if you have the knowledge, is a detailed guide on CWM Edify scripting. I'm sure many people would find that useful, especially me. There doesn't seem to be a lot of good guides or information on the language, at least I can't find them yet. If you have any good links I'd definitely appreciate it as well.
Here's another bit of information, that answered a question I had....
In case anyone else has this question...
Here is the answer from:
http://android.stackexchange.com/qu...ter-no-sd-ext-found-skipping-backup-of-sd-ext
" This means you do not have an ext3/4 partition on your sdcard. This really ins't a big deal, this is like a legacy part of the nandroid backup process. CM doesn't "officially" support the sd-ext partition any more anyhow."
Hope it helps someone else... In the end, the answer is pretty straight forward.
Sent From my Two Tin Cans & String Device on The Wookie Network
Sent from Down The Rabbit Hole, using Tapatalk 2
Hi!
So I'm running civato's FLEXREAPER-R6 ICS 4.0.3 ROM on my Iconia A500 after using timmyDean's "root-3.2.1-V4.7z" method to root my stock HC 3.2.1 ROM. I had ClockworkMod Recovery v5.0.2.3 (rev 1.3.4 by thor2002ro) and was unable to do a full Nandroid backup so I upgraded to the latest ClockworkMod Recovery v5.5.0.x (rev 1.7 by thor2002ro) but I'm still having the same issue.
When I try to backup data I get the error "Error making a backup image of /data!" and then when I look at the sdcard in \clockworkmod\backup\YYYY-MM-DD.HH.MM.SS I see "data.ext4.tar" and the size is 4,294,967,296 bytes), which is exactly the 4GB filesize limit on a FAT32 partition. Looking inside the data.ext4.tar file, I see data/app and all the .APK installer files for apps installed on my Iconia plus a few .ZIP files as well. ES File Explorer won't show me how big /data/app is but DiskUsage says it's 4.7GB. From what I'm reading Android needs a copy of all the APK user-installed app installation files of in /data/app so that it can restore the default data/configuration when requested (under Settings/Apps/Manage Apps/Delete Data & Cache). So...how can I get a successful Nandroid backup if I have more than 4GB of apps installed? Can the data portion be broken up into <4GB chunks? Or can Nandroid/Recovery be updated to support exFAT or NTFS? Or would it be safe to exclude /data/app from the backups?
Since I've been unable to do the Recovery/Nandroid backup of "data", I've been doing a custom backup of everything except for data and then backing up all my installed apps and settings from inside the OS with Titanium Backup. But with this method, a catastrophic failure would still require me to use Recovery to restore the OS and then use Titanium to restore app my apps.
What's the solution?
You can try doing several backups, in other words, do a nandroid backup of /data separate from the other back ups of /system /boot /recovery and other paritions. Then when you have to restore, first restore the backup with your system partitions and then restore your data partition afterwards. You are probably backing up to many things to have a nandroid file that large anyway. When you do a full data wipe it does not wipe the data on the internal sd card only the data on the data partition.
cruise350 said:
You can try doing several backups, in other words, do a nandroid backup of /data separate from the other back ups of /system /boot /recovery and other paritions. Then when you have to restore, first restore the backup with your system partitions and then restore your data partition afterwards. You are probably backing up to many things to have a nandroid file that large anyway. When you do a full data wipe it does not wipe the data on the internal sd card only the data on the data partition.
Click to expand...
Click to collapse
Hey cruise350! I have an Evo 3D as well. I'm running Virus's "Eternity 3.0 r193 ROM" with the Stock theme on my Evo 3D, how about you? Anyway, I have tried doing separate Nandroid backups. I can backup everything but "data" and that will complete just fine. I don't see any way to break up the "data" backup into multiple smaller backups. But as I said, if I backup everything else with Nandroid, I feel pretty confident that I can restore all my apps/data with Titanium.
Would it be safe to try to move /data/app temporarily somewhere else (such as /mnt/sdcard), do the Nandroid data backup, and then move it back?
It seems to me that doing full wipe (system, data, cache, dalvik cache, superwipe, etc) would wipe out /data and everything underneath (including /data/apps) but that it would get recreated automatically when I restore everything with TB, right?
The way to get rid of that problem once and for all is to format your SD card as EXT4... You won't be able to read it with non-Linux (or BSD) OSes after that, though. Mounting via USB should still work, as this doesn't access the SD filesystem directly...
I would try changing recoveries then, I am using RA recovery and it has a compress backup feature. It takes about 45 minutes to do a nandroid when compressing but it cuts the size of the backup significantly. I bet RA will solve your problem though. And, I am running Steelrom on my Evo 3d. It's really stable, has some good tweaks, and the battery life is incredible.
haag498 said:
The way to get rid of that problem once and for all is to format your SD card as EXT4... You won't be able to read it with non-Linux (or BSD) OSes after that, though. Mounting via USB should still work, as this doesn't access the SD filesystem directly...
Click to expand...
Click to collapse
Thanks, haag498. That's an interesting idea. So any Android OS or Recovery would be able to read/write to an EXT4-fomatted SD card? It would work in both my Iconia A500 and my Evo 3D both in Recovery and inside the OS? That might be a good option. I see that EXT4 supports very large filesizes so that problem would go away. What tool would you recommend for formatting the SD card with that filesystem? Can it be done from inside Android?
Not being able to mount the filesystem natively in Windows might present occasional inconveniences but it shouldn't be a major problem as long as the Android devices can present the storage as USB Mass Storage mode. That being said, I have some issues with the Iconia when accessing the storage over USB. Namely, when I try to move files and folder off the device or delete them from Windows when attached via USB, the task often won't complete. I've worked around the problem by just doing internal moves, deletes and renames from inside Android (using ASTRO or ES File Explorer) and, if necessary, mounting the SD card directly in my Windows PC, which won't be possible anymore.
cruise350 said:
I would try changing recoveries then, I am using RA recovery and it has a compress backup feature. It takes about 45 minutes to do a nandroid when compressing but it cuts the size of the backup significantly. I bet RA will solve your problem though. And, I am running Steelrom on my Evo 3d. It's really stable, has some good tweaks, and the battery life is incredible.
Click to expand...
Click to collapse
Okay...so if I wanted to install RA Recovery instead, would I flash that from inside CMR? I have "Acer Recovery Installer" installed as well but I believe the version of CMR I'm using is newer than what that tool would have been able to install. So, what's the procedure to switch to RA from CMR? Any other features of RA that you prefer?
JesseAaronSafir said:
Okay...so if I wanted to install RA Recovery instead, would I flash that from inside CMR? I have "Acer Recovery Installer" installed as well but I believe the version of CMR I'm using is newer than what that tool would have been able to install. So, what's the procedure to switch to RA from CMR? Any other features of RA that you prefer?
Click to expand...
Click to collapse
You can flash from within CWM. If you look in the RA threads, you will find some flashable versions. I use 3.15, as I have been lazy to update to 3.16.
No wipes needed. Just install zip from SD
http://forum.xda-developers.com/showpost.php?p=22392691&postcount=104
JesseAaronSafir said:
Thanks, haag498. That's an interesting idea. So any Android OS or Recovery would be able to read/write to an EXT4-fomatted SD card?
Click to expand...
Click to collapse
They should, if they're using a reasonably up-to-date Linux kernel, as EXT4 is built in for these... If you want to be absolutely sure, use EXT2/3 (they're pretty much identical from a user point of view), which still support large files and all, but are somewhat slower (and they can't use more than 4TB, which shouldn't be an issue anyway...).
JesseAaronSafir said:
It would work in both my Iconia A500 and my Evo 3D both in Recovery and inside the OS?
Click to expand...
Click to collapse
Read above.
JesseAaronSafir said:
That might be a good option. I see that EXT4 supports very large filesizes so that problem would go away. What tool would you recommend for formatting the SD card with that filesystem? Can it be done from inside Android?
Click to expand...
Click to collapse
Formatting the SD card can be done from any Linux live CD (Ubuntu, Knoppix, ...) or from within Android (if you're rooted and have a chroot Linux) using parted (or cfdisk) or some GUI tool like gparted... Internally, they'll all use mkfs.ext4, which is anything but user-friendly, though...
JesseAaronSafir said:
Not being able to mount the filesystem natively in Windows might present occasional inconveniences but it shouldn't be a major problem as long as the Android devices can present the storage as USB Mass Storage mode. That being said, I have some issues with the Iconia when accessing the storage over USB. Namely, when I try to move files and folder off the device or delete them from Windows when attached via USB, the task often won't complete. I've worked around the problem by just doing internal moves, deletes and renames from inside Android (using ASTRO or ES File Explorer) and, if necessary, mounting the SD card directly in my Windows PC, which won't be possible anymore.
Click to expand...
Click to collapse
That's actually a known problem... I usually just use a NAS for data exchange, as it has plenty of space and good speed, even on WiFi. Another way to do it would be a USB drive (2.5'' hdds tend to need more power for spin-up than they get from the internal port, though). Also, as I use Linux on all my computers, mounting EXT4 partitions is no problem for me ...
This is completely pulled off of my other thread in the HOX+ section
our device is a data/media device which is why usb mount don't work
here's a link that explains it all
http://teamw.in/DataMedia
and part of the convo with dees_troy is below
<Dees_Troy> Nope, it will *never* work on a data/media device
<Dees_Troy> read and learn: http://teamw.in/DataMedia
<WinBot> [Link] http://tinyw.in/lstO :: What is a data media device? | TeamWin
<Dees_Troy> definitely worth understanding
<Dees_Troy> at some point we're going to try to kang in MTP for recovery
<Lloir> so for now then it's sideload or from inside the rom
<Dees_Troy> or adb push
<Lloir> aye
<Dees_Troy> or gtfo
<*****> so cant mount usb storage with newer devices...hmm one x did guess this is where confusion at least on my part came to be
<Lloir> lmao Dees_Troy
<Dees_Troy> one x wasn't a data media device
YOU MUST either transfer the rom\boot\porn\audio\mods while the phone is on or use adb push or even sideload when in recovery, THIS IS THE ONLY way
IF you want to read without clicking the link i'll whack it up in #2
What is a data media device?
I'm writing this page because there seems to be a lot of confusion about how many of the newer Android devices work. Starting in Honeycomb 3.0 with the Xoom, Google changed the way that they handled storage. Instead of having a "data" partition with your apps and a separate "sdcard" partition for storage, Google started giving you a single, very large data partition. Inside /data is a folder at /data/media that contains all of the contents of what you think of as your internal sdcard.
Since /data/media is part of /data, we pretty much never actually format the data partition. Formatting data, of course, also removes the media folder that contains the internal sdcard. When you choose a factory reset, instead of formatting, we use rm -rf commands to remove all the folders except for the media folder so that we can remove all of your apps and settings while leaving your "sdcard" intact. In TWRP we also have a wipe internal storage option that rm -rf's the media folder and a "Format Data" option that formats to recreate the entire file system in case something goes completely wrong or to remove device encryption.
When you're booted to Android, Android fuses the media folder to /sdcard and emulates a FAT files system that doesn't have permissions for legacy apps. We don't currently have fuse in recovery, so we just add an extra mount command to mount /data/media to /sdcard so in recovery you still have to worry about permissions on /sdcard.
Because the "internal sdcard" is not a true FAT file system, you can't mount it via USB storage. Well, that's not technically true, but the vast majority of people use Windows computers and Windows doesn't recognize ext4. If we were to allow you to mount the data partition via USB storage, Windows would claim that the device wasn't formatted and offer to format it for you, which, as you can imagine, would be a disaster. The whole ext4 setup is another reason that Android switched to using MTP for transferring files. Most of these devices don't have the necessary kernel configuration to even support USB storage mode, so it's not very easy to enable USB storage if we even wanted to try. Unfortunately at this time, MTP isn't available in recovery, so if you have no other option, you will have to use adb to push and pull files to/from your device.
As a special note, if you choose to do a factory reset from your ROM, even if the ROM says that it will wipe everything including the internal storage, well, that's not what TWRP will do. A stock AOSP recovery would format data including the "sdcard" but TWRP will use its regular factory reset setup that leaves the internal storage intact.
There are a couple of nice gains with using this setup vs the old data + FAT storage partition. With /data/media you, as the user get more control over how you use your storage. If you have a ton of apps, then that's no problem since you have a huge data partition to work with. If you don't have a lot of apps, you get more room to use for storing things like movies. Further, ext4 doesn't suffer from the 4GB file size limit that FAT has, so you can have a large, high-def movie on your device if you like. I'm sure another motivating factor was to get Android away from using FAT which is a Microsoft creation. Performance on ext4 in Android is also probably better than FAT. As a downside, data media devices tend to store a lot more app data in the "data" section and so backups on these devices tend to be larger.
Thank you for this post. I had been a bit curious about this. I have Evo LTE. But I also Boughy a family member a GNex that I have to maintain. I know that my Evo, I can plug into windows, and when I select USB transfer (not in recovery), it mounts my internal storage (not ext_SD) , and it shows as removable drive in windows. But,....when I plug in GNex, it shows up as GNex , not removable drive H. I always wondered a bit about what this all means.
Thanks for the info. :thumbup:
Sent from my EVO using xda premium
Thanks for the useful post.
If I make a nandroid backup for the whole device, will it exclude the /data/media folder? Because on my old phone the nandroid backup doesn't include /sdcard.
romitkin said:
Thanks for the useful post.
If I make a nandroid backup for the whole device, will it exclude the /data/media folder? Because on my old phone the nandroid backup doesn't include /sdcard.
Click to expand...
Click to collapse
Yes it does, we are past the point where that causes issues.
Everyone just needs to get used to the data/media thing. And learn how to use adb side load
I predict a whole bunch of "bricks" due to people not informing themselves on how the phone works and how to use adb
Sent from my One X using Tapatalk 2
A little bit from my side as well I hope someone will find this helpful. Virtual SD card on Android
Can't you use USB Host if you got recovery installed as well? I think I've read that somewhere...
mike1986. said:
A little bit from my side as well I hope someone will find this helpful. Virtual SD card on Android
Click to expand...
Click to collapse
Link broken, here is the correct URL:
http://android-revolution-hd.blogspot.com/2013/03/virtual-sd-card-on-android.html
Oh and bump for anyone new to the idea of a "data/media" device. You're not in Kansas anymore.
NxNW said:
Link broken, here is the correct URL:
http://android-revolution-hd.blogspot.com/2013/03/virtual-sd-card-on-android.html
Oh and bump for anyone new to the idea of a "data/media" device. You're not in Kansas anymore.
Click to expand...
Click to collapse
Lloir, thanks for sharing and good explanation. MTP makes sense and on my One, this way file transfers are simple and fast. However there are two things I dislike about MTP right now:
When you copy files to the device, on some file types it throws a warning that the device might not be able to read the file. This interrupts the file transfer and I have to confirm I want to copy the file to the device. On an older MP3 player I have, I could deactivate this by editing a device capabilities XML file. On the One, I did not find such a file. Perhaps an option in the MTP deamon?
When I am transferring files, I can't browse through other folders at the same time. It says the device is busy.
Is there a way to solve those two issues or "is it what it is"?
Lloir said:
Windows would claim that the device wasn't formatted and offer to format it for you, which, as you can imagine, would be a disaster
Click to expand...
Click to collapse
I did that on a device. Windows offered to format and I did it. Man that was not good! 2 hours later after manually restoring the partition values I was OK and the most amazing thing all my data was there perfect and untouched :silly: :highfive:
Thanks for that great explanation. Been having some issues with windows and android. Nothing big just had to sideload my ROM and killed my "sdcard" at least now I know why
I accidentally deleted a folder on my One's internal storage ( "/storage/sdcard0" which is also known as "/sdcard/" and linked to "/storage/emulated/0/" ) yesterday. There have been some documents that were deleted so I tried to recover them.
Here on xda we have a comprehensive guide how to recover internal storage. The problem is that other than SD card based external storage, internal storage is ext4 formatted and not visible to a computer as mass storage (content is transferred via MTP) hence common recovery tools such as testdisk, recuva, r-studio can't search the file system on a low level to recover lost files from an android's internal storage.
The solution to this is to copy over the entire (raw) data partition to your computer where you can proceed to have recovery tools search for your lost data. This can be done via adb. BusyBox and Root is required.
The detailed recovery/imaging process is described here:
http://forum.xda-developers.com/showthread.php?t=2143188
http://forum.xda-developers.com/showthread.php?t=1994705
BusyBox includes the linux "dd" command to create a bit-to-bit image of your data partition and "nc" that is used to pipe the data directly off the phone to your computer so nothing will get overwritten.
The userdata partition on the One is /dev/block/mmcblk0p37 and roughly about 25GB on 32GB Ones or 55GB on a 64GB One in size. It takes some hours to copy it over to your computer (was around 5h for my 64gig variant, 4MB/s avg).
After finishing that, you let multiple recovery tools of your choice work their magic on the huge raw partition backup, just to realize that other than existing data no deleted files are found.
Time to investigate further so I took another One which had the 4.2.2 based ARHD 10.2 installed, factory reset the device and filled it up with data. Then I deleted the whole userdata via my MTP-connected computer and immediately started over the imaging process. A few hours later I hex-edited the partition backup and found that 80% of the partition was zeros. My recovery tools still found existing data in /data/ that obviously have not been touched by me when deleting the "internal storage" through my computer as it is not accessible that way.
From my investigation so far, to me it seems that there is some kind of TRIM'ming or instant garbage collection going on to clean up unused NAND cells which carry previously deleted data. That is what is done on SSDs to maintain write speeds, which is a good thing actually. If that is the case, there would be virtually no chance to recover lost data as it gets wiped/zero'ed immediately.
What I want to find out is whether this behavior is from kernel or hardware, specifically internal flash controller. What are your thoughts?
Hope that helps others a bit.
Most phone NANDS have Trim activated. The HoX however did not, and that's why apps like FSTrim exists, to force a TRIM pass. Greatly smoothed out the random I/O lags even when scrolling through Sense.
If your using elementalx kernel it runs an fstrim command on boot and installs the binary when you flash the kernel ....
Its from an fstrim init.d mod I made for the hox which is being used in that kernel on the m7...
As for fstrim if your not using that kernel, I'm sure unless the fstrim file is in system/bin / xbin htc/Qualcomm arnt using it.
backfromthestorm said:
If your using elementalx kernel it runs an fstrim command on boot and installs the binary when you flash the kernel ....
Its from an fstrim init.d mod I made for the hox which is being used in that kernel on the m7...
As for fstrim if your not using that kernel, I'm sure unless the fstrim file is in system/bin / xbin htc/Qualcomm arnt using it.
Click to expand...
Click to collapse
I checked it and the file is not there. I didn't use elementalx kernel or any non-stock kernel when it happened. I did not reboot the phone before I made the image with dd.
There must be something in the stock kernel or nand controller...
Are the partitions mounted with the discard option?
flar2 said:
Are the partitions mounted with the discard option?
Click to expand...
Click to collapse
Indeed the data partition is mounted with discard. That might explain it. The file system reports free space to the controller immediately which kicks off the cleaning.
Note from the Author -
I am moving on to the N5 now and ditching my S3. I will continue to maintain this thread, however - please do PM me if you think that something needs to be changed or updated in this thread as I doubt I will be answering questions within the thread as much. Please don't PM support questions to me. Only PM updates that need to be made in the thread.
It's been a blast!
Regards
Dan
S3 Storage (Data Loss Recovery / Prevention / Info)
This thread is intended to give you an overview of some of the Storage of the S3 from a Data Loss and recovery perspective. It is not intended to cover USB sticks or mods to Swap / Mount other storage. It is solely to cover day-to-day data concerns and give a background to how these things work
Please note, if you have recently swapped between Android 4.1 and 4.2 and cannot find your sdcard data, you need to read [Info] Flashed 4.2? Can't find your /sdcard data?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Before we get started...
Here are a couple of threads you should get familiar with before posting on XDA.
Forum Rules - use Search before posting
Post Questions or Support queries in Q&A, NOT General
Backround of Android storage (Pre-S3)
Firstly, I think we need to understand how Android worked historically as this will help us to understand how the S3 works now.
A legacy android device, lets pretend the HTC desire on Android 2.2 as this was a standard configuration at the time. It had 2 major partitions (and several minor ones which are irrelevant to this topic). It has the /system partition and the /data partition. These were partitions of the internal NAND flash memory.
/system is where the Android operating system lives. The user could not delete or change anything in here (unless you were rooted). All the software that came with the phone was installed in the /system partition
/data is where all the userdata goes. Whenever you installed an app from the market, it installed to /data/app and it put all it's important data into /data/data. Also any system settings you changed (Wallpaper, ringtones etc) all were stored in /data/data. When you did a factory reset, it wiped /data and everything in it.
Of course, having these 2 partitions was not enough for everyday use. There was no where to store your music, photos, documents etc. /data is just for app data and settings. So this is where /sdcard comes in
/sdcard is the Android mount point for the External SD card in this legacy android device. This means that when you inserted a Micro SD card, Android used /sdcard as it's internal reference to where the card's storage is. The /sdcard was a necessity before you could take photos. Over time, bigger apps started to put other data here. For example, a GPS / Map application would store its apk (application package) in /data/app and store your personal configuration settings in /data/data but it may download and store offline maps somewhere on the /sdcard. In older devices, the internal Memory (NAND Flash) was usually too small to allow much data on it. Many users would have to root to get more storage space or keep uninstalling apps to keep the "low on space" warnings at bay
How the S3 is different
Well, the S3 is substantially different. There are of course SOME similarities. For example, the S3 still has internal NAND Flash Memory. This is often referred to as the eMMC (Embedded MultiMedia Card) - which still contains the /system and /data partitions, used in exactly the same way.
The main difference is /sdcard. The S3 is designed specifically so using an external micro sd card is NOT a necessity. It has a larger NAND Flash internal memory (eMMC) so it can also have an "internal SD card". This is where people start to get confused. The entire internal memory is an eMMC which is essentially an internal SD card, however a partition of that internal memory is /sdcard.
OK, I know - let me explain. /sdcard is a mount point that Android uses to know where to store /sdcard data. But on the S3, instead of storing it on a required external sd card, it points to an internal memory partition. Now here is the clever bit. The /sdcard actually points to /data/media (or /data/media/0 in Android 4.2 onwards). So you continue to have your /data partition, but within /data you have:
/data/app
/data/data
/data/media
The clever thing is that the file system that android uses for /system and /data is a Linux file system called Extended FS. In our case, we use the Ext 4 file system. This is important to understand because these file systems do not work with Windows so an external SD card would usually be Fat 32 file system, or exFAT so we could plug it into our windows computers and read the contents. What Samsung have had to do is use the FUSE file system to allow /sdcard (or /data/media) to exist as a FAT file system within the EXT 4 file system. Clever stuff. But it has it's pro's and cons...
You lost me at file system
All electronic systems that have an operating system and store data use a file system. Think of it in it's simplest form. Imagine a school text book. It has lots of chapters about different things. It has a "Table of Contents" in the first few pages, telling you where each chapter in the book is so if you want to know what page chapter 13 is on, you look in the contents and find the page and go straight there - The alternative is looking through each page individually to find the chapter. Not a quick process.
Well data storage works the same. When you put a file on a hard drive, sdcard, USB stick (or whatever) it is written to a specific location. When it is written to this location, the location is added to the file system. So when you put word.doc onto the drive, The file system is informed of the (very complicated) location of the file. When you tell Windows, Android (or whatever) that you want to open word.doc, the operating system consults the File system and goes to retrieve the data from its true and real (yet very complicated) location on the drive.
There are many file system types still in use today. Usually they are operating system specific. For example, Ext 4 is a Linux file system (and Android by Proxy as it is Linux kernel based) and Windows cannot read Ext file systems. Similarly, exFAT is a Microsoft file system (also used for sdcards on the S3) and cannot be used (easily) on Linux machines. Since most everyday users of the S3 are Windows users, you can see now hopefully why it was important for Sasmung to use "magic" and implement FUSE to allow an exFAT file system to be used for /sdcard, within the Ext 4 partition of /data
Did I REALLY need to know ALL that?
You know what? Probably not but it may go some way to help understand the limitations we will cover later on.
A bit more info for the S3
Obviously, the internal memory supplied with the S3 may not be enough for all users so they added the ability to add expanded memory in the form of the Micro SD card. Android uses the Mount point of /extSdCard now, instead of /sdcard like it used for legacy devices - because /sdcard is already in use elsewhere.
One thing many of you have probably noticed is that with the S3, there is no option to mount the /sdcard or /extSdCard as USB Mass storage on your computer. You must use MTP or PTP.
PTP - Photo Transfer Protocol. When you connect your S3 to your computer using PTP, Your computer sees it as a camera. It will show photos on your "camera" and will set about implementing the default camera options (such as suggesting you import your photos) etc. It won't show documents or other media necessarily.
MTP - Media Transfer Protocol. When you connect your S3 to your computer, it will be seen as a media player. This should allow you full access to all the files on there, including word documents and the such like.
One of the reasons for this is that because /sdcard points to something using the FUSE file system and is not a true partition, it would be difficult to allow it to be used as USB Mass Storage. It may or may not be possible but the biggest advantage of using MTP / PTP is that the computer and the S3 can both access the internal memory at the same time. With USB Mass Storage (UMS) this is quite awkward and can result in errors.
Deleting data
This is partially why we needed to understand a little about file systems. So I could explain to you how data is handled when it is deleted.
As I explained earlier, when you write a file to memory, a corresponding entry is written to the file system to advise the OS where the data is. Sure, you may think you are writing the file to /sdcard/documents/work directory on the internal memory, but in reality these directories or folders do not actually exist at a memory hardware level. The data is written to a block and the file system is informed where that block is, how big the file is, what directory it should appear in to the OS etc. When a file is written the memory, the OS see's the available space go down and the used space go up. All this information comes from the file system.
When you delete the file, the actual data is NOT deleted. It remains where it is on the memory. The block is not overwritten. When the OS is told by the user to delete the file, the File system entry is deleted. This changes the free/used space as the file system is no longer accounting for the data, however the truth is the data still exists. When the next request to write a file to the memory comes from the OS, the file system will think the block where the old data was is empty and will overwrite it.
It is this difference between the file system and reality that allows data to be recovered by external software. if you do not write any data to the memory, external software can scan the memory for data whilst bypassing the file system all together. Ff course the window is small. You only have a very limited time to recover data before the file system allows the data to be overwritten with a new entry.
This is not just true of a deleted file. Even formatting the memory (which is actually just re-creating a new, blank file system) leaves all the data in tact behind-the-scenes and can all still be recovered until you start writing data to the memory. Cool huh?
Wow, all this time I've been stressing, is it really that simple?
Awwww snap! You got me. No it is not that simple. All this PC software, example: Piriform recuva only works on a computer drive. In windows, imagine this is anything with a Drive Letter. C: drive etc.
The only way to get a drive letter on your sdcard is to use USB Mass Storage mode, which as previously discussed - is not possible on your S3 (unless you are rooted, you can mount USB mass storage in custom recovery or use a UMS app from Play). The alternative is to use a card reader on your PC and put the sdcard in it.
There are also apps like Undelete for root users - which again, you guessed it - requires root. So if you're not rooted, it's simplest to use a card reader which can be bought for peanuts.
It's worth mentioning, NONE OF THE ABOVE will work with /sdcard on internal memory. It is not possible to get your data back once deleted from internal memory. Once gone, it's gone forever. You can only restore from /extSdCard (removable, external SDcard)
Phone won't boot, can I get my data back from internal memory?
Let's start by saying, it depends why your phone won't boot. If it's an SDS (Sudden Death Syndrome) type issue, where your internal eMMC (NAND FLash memory) has failed, then no. However, if you believe this is not the case then you can get your /sdcard data using adb BUT you need a custom recovery to be flashed via Odin before you do this. Read [REF] Understanding the basics before rooting your S3
However, if out of curiosity - you do still want to get your data off, using adb , read below:
Pre requisite is having adb "installed" on your windows PC. Download THIS file and follow the instructions in the readme.
You need to observe the following. For android 4.1.x and earlier, /data/media for android 4.2.x and newer, /data/media/0 - I will assume 4.2.2 for this guide,.
1) Boot into recovery, connect usb and go to "mounts and storage". Toggle the "mount data" options to mount these partitions. Tip, when mounted, the option then becomes "unmount data"
2) Open "cmd" in Windows and type the below code, which will copy all your data to a folder called sdcard on your windows desktop
Code:
adb pull /data/media/0/ c:\users\rootsu\desktop\sdcard
Also note, this assumes you have windows vista or newer. Also, it assumes your windows username is rootsu.
That's it, simple.
Display and Digitiser won't work, can I get my data back from internal memory?
You can use adb and a custom recovery to pull data from your /sdcard or even app data from /data/data
Pre requisite is having adb "installed" on your windows PC. Download THIS file and follow the instructions in the readme.
You need to observe the following. For android 4.1.x and earlier, /data/media for android 4.2.x and newer, /data/media/0 - I will assume 4.2.2 for this guide,.
1) Boot into recovery, connect usb and go to "mounts and storage". Toggle the "mount data" options to mount these partitions. Tip, when mounted, the option then becomes "unmount data"
2) Open "cmd" in Windows and type the below code, which will copy all your data to a folder called sdcard on your windows desktop
Code:
adb pull /data/media/0/ c:\users\rootsu\desktop\sdcard
Other things you may want to pull.....
Code:
adb pull /data/data/com.android.providers.telephony/databases/mmssms.db c:\users\rootsu\desktop\sdcard
Code:
adb pull /data/data/com.android.providers.contacts/databases/contacts2.db c:\users\rootsu\desktop\sdcard
Also note, this assumes you have windows vista or newer. Also, it assumes your windows username is rootsu.
That's it, simple.
Data corruption
When data becomes corrupt, there's really not a lot you can do. The file system knows where the data is already. If it's corrupt, you're stuck. Most common causes of corruption are:
1) Dirty unmount of /sdcard. SD card pulled out whilst it is being written to / phone shuts off whilst being written to. SOMETIMES - Plugging the card into a card reader in windows, Windows will ask to fix it and MAY fix it.
2) Fake SD card. This is really the MOST common. Get a card reader ans use:
h2testw.exe for windows to test your card in a card reader. Set it to read the full size of the card, which will take hours but well worth it.
If you get a result like this:
Code:
Warning: Only 63995 of 63996 MByte tested.
The media is likely to be defective.
3.8 GByte OK (8072512 sectors)
58.6 GByte DATA LOST (122989248 sectors)
Details:2 MByte overwritten (4096 sectors)
...Then you have a fake card, that is really 4 GB. I'll explain this.
Commonly, fake cards are reprogrammed to "think" they are high capacity cards, such as 32 GB or 64 GB to defraud buyers out of money. This is common on eBay (Never buy cards from eBay).
When these cards are formatted, the file system also thinks it is this fake capacity. Normally, when a card is full, the file system will report to the OS there is no more space and this prevents additional writes to the card. However, in the case where the card is 4GB and the File system thinks it is 64 GB, the tricked file system doesn't know the card is full. The file system keeps allowing data to be written to the card, over writing the existing data but without replacing the file system entries. The file system thinks data that has been overwritten hasn't been overwritten so when you try to open one of these files, it is essentially "corrupt" or non-existent.
Preventing data loss
Time to wise up guys. It is possible to recover data off your removable media, but internal memory - very unlikely. No apps on your PC or Android will help with deleted data. So you need to backup.
Dropbox - Use dropbox to automatically upload your photos to online storage.
Foldersync - Use FolderSync to upload important sdcard files to your dropbox account, or better yet - got a computer thats always on at home? Set foldersync to schedule a sync over wifi whilst you're asleep.
Other info
Interesting tidbits
Quite an exhaustive reference guide you got here rootSU thanks this will sure come handy for all of us :good:
Cheers
Thank you very much for taking the time to write this. It's a non academic approach to a sum of keywords and all of them are explained in such a manner that it would be almost impossible to misunderstand
Nice!
Nice post!
There are a few other interesting tidbits of info that might be worth mentioning:
- eMMC has an internal micro-controller that runs very specific firmware (and SDS was mainly caused by a bug in that firmware)
- eMMC (just like SSD) has specific writing/erasing limits and commands to deal with that - as a very general idea it can write about 4k at a time but can only erase in much larger blocks - like 64k (at least, but a 16GB model could have a much bigger block); normally on the same erase-size block there is very special list maintained, and based on that list wear leveling is implemented;
- all flash-based memory AGES - there is only a limited amount of erase/writes cycles possible before a point where the info is no longer reliably-stored; in some models that value can be incredibly small! to avoid writing more to some regions than other a mechanism call wear leveling is implemented; that one can have a big impact on both speed and reliability (but really don't expect it to create miracles)
- since it is very important for the speed and reliability of the flash memory to return unused blocks to this internal lists there are special TRIM commands that informs the firmware that the block can be garbage-collected; with an OS that supports TRIM, when a file is erased the blocks are also TRIMmed; this is one extra level that makes recovery basically impossible under normal circumstances
- this does not really mean that things are completely impossible to recover, just that you might need to spend so much on it that recovery would be impractical for any item worth less than 100000 US$ to 1 million US$
EDIT
- also just as with SSD it is not a bad idea to keep a good percentage of the flash memory free - IMHO at least 4GB for 16GB models, 6-8GB for 32GB models - that will improve performance since fragmentation (CLARIFICATION - free-space fragmentation) will grow much slower
- unfortunately there is no program for eMMC similar to smartctl (or any other SMART-data reading program) on normal SATA/IDE/SCSI disks - there seem to be some proprietary commands that are somehow similar but those are generally undocumented.
xclub_101 said:
Nice post!
Click to expand...
Click to collapse
I've put a link to your post in post 1. Where as it's not strictly relevant to my point, it is interesting stuff....
Fragmentation isn't an issue on ssd's. Its an issue on hdd because the head must physically move to another area of the Platter to get the data. That's the slow down. Defrag of a hdd moves all the used blocks (data) together so the actuator doesn't need to move much.
Performance degrades over time on ssds because every write, if data already exists must be erased too. But this hasn't really been an issue so much since TRIM became widely available.
-----------------------
Sent via tapatalk.
I do NOT reply to support queries over PM. Please keep support queries to the Q&A section, so that others may benefit
rootSU said:
...
Fragmentation isn't an issue on ssd's.
...
Click to expand...
Click to collapse
Thank you.
Also sorry for the misunderstanding with my contraction - what I wanted to say was free space fragmentation - that one does matter a lot on solid-state memory because of the garbage collection and some controllers have been famous for having a huge drop in performance with little free space - I will try to also correct that post.
xclub_101 said:
Sorry, I used a misleading contraction - what I wanted to say was free space fragmentation - that one does matter a lot on solid-state memory because of the garbage collection and some controllers have been famous for having a huge drop in performance with little free space - I will try to also correct that post.
Click to expand...
Click to collapse
Yep, it's true about Garbage collection, but TRIM *should* handle this nicely as should "over provisioning" although probably, some cheap SSD's may not over provision.
EDIT> Actually (sorry everyone for off topic) if you're interested in SSD's, these articles are a "fun" read... (I put fun in speech marks as it depends how geeky you are )
http://en.wikipedia.org/wiki/Trim_(computing)
http://www.pcworld.com/article/2038...-ssds-what-makes-these-speedy-drives-hum.html
Update to post 1:
Note from the Author -
I am moving on to the N5 now and ditching my S3. I will continue to maintain this thread, however - please do PM me if you think that something needs to be changed or updated in this thread as I doubt I will be answering questions within the thread as much. Please don't PM support questions to me. Only PM updates that need to be made in the thread.
It's been a blast!
Regards
Dan
Awesome bits of info. This is the game changer. I learned a whole lot just by reading here in XDA. I've only been using Android for a few weeks but thanks to XDA, I've already rooted, installed a bunch of apps and kept my OCD in check.
my device memory has corrupted and when i start recovery mode i get "E: faild to mount /cash (invalid argument) "