Lately, I've been flashing a bunch of different ROMs, and in each one, they require you to have a certain amount of your memory partitioned. I'm not too experienced in this particular area and I've been wondering what is the point of all the partitioning?
Why can't we just have one partition and run things off of that like with a computer running on windows??
What are the differences between ext2 and ext3 and so on?
So far, I've only been able to find out that the swap partition is for memory extension when the phone is currently using all of its ram, it can convert some of the sd card's memory to use for programs. Can anyone provide more insight on this?
I've asked myself the same questions .... hope someone will explain...
hacker01 said:
Lately, I've been flashing a bunch of different ROMs, and in each one, they require you to have a certain amount of your memory partitioned. I'm not too experienced in this particular area and I've been wondering what is the point of all the partitioning?
Why can't we just have one partition and run things off of that like with a computer running on windows??
What are the differences between ext2 and ext3 and so on?
So far, I've only been able to find out that the swap partition is for memory extension when the phone is currently using all of its ram, it can convert some of the sd card's memory to use for programs. Can anyone provide more insight on this?
Click to expand...
Click to collapse
It would be helpful if you mentioned what phone you're using.
Generally the reason you have a /data and /system partition separately are so that you can either upgrade or reinstall Android without losing your data. If you reflashed whatever ROM you're on right now again, without wiping anything, all of your apps and settings would still be there (although any mods you flashed to modify the ROM itself would need to be flashed again).
System - Holds Android itself and any apps that came with the ROM. Some ROMs (or rather updater scripts inside of ZIP files) will install some apps in the data partition to save space.
Data - Your settings and any applications you installed.
Sometimes you WILL have to wipe everything to go to a different ROM, but for the most part if you're on an official ROM that came with your phone, and your carrier pushes an update, you don't have to.
I'm guessing you have an older phone if you need to make a swap file. A swap file is like RAM in the form of a file; if your phone runs out of usable RAM, it can use the [slower, but useful] swap file, which is like memory you reserve from storage [your MicroSD card]. Windows and other OS's use swap files too, but given how much RAM we have in computers today, we hardly ever use it.
EXT 2 fs - A non-journaling file system. It's quicker than EXT 3 and takes up less space for itself in memory (not for files, just for itself), but it's more susceptible to corruption if you randomly turn off the phone while a file is being accessed.
EXT 3 fs - A journaling file system, which means that it keeps track of any file operations within itself. While it's slower than EXT 2 and takes up more space, it is more reliable and is safer in terms of file integrity.
There's also EXT 4, but only certain phones are compatible with that, mostly Samsung Galaxy S phones.
tl;dr: It keeps everything modular.
Thanks for the explanation. It helped
Sent from my PC36100 using XDA Premium App
I think this is moronic , an ext4 partition to maintain the system and a swap partition for oom situations and cached processes is enough.
Obviously there are some benefits like if your system partition is corrupted you don't lose the data but since most non-dev users will end up either reflashing the device from scratch or take it to the service center anyway , it's not logical.
Plus , i've never seen an ext4 partition get corrupted on hdds let alone ssds...
USB connectivity is solved by MTP and you can do what you cannot with mtp with adb...
It would save the developers from a lot of work and not just devs on xda , manufacturers' own devs.
I looked at my partition table and there are over 10 partitions , what the f... is this i mean ?
When you compile a new kernel , you need to write scripts mounting over 10 partitions , manually...
and i'm not even counting the flags that refer to those partitions...
I had to learn a lot of things to compile a kernel for our device from the source , now i find out that i have to do this huge manual labor for no logical reason , i'm pissed off naturally.
Does anybody have something , i missed ? or Am i right on the spot ?
I'm really hoping that i missed something , because if i didn't then it'd mean that people who made this system are idiots.
There are a plethora of apps on the PlayStore that claim to actually "resize" your eMMC partitions. How well do they work? Can you just install it and change your say internal partition from 500MB to 1GB?
To the best of my knowledge, partition tables are kept well hidden and behind lots of complexities on various devices. The repartitioning methods are different on each device and too complex to try out (I know many on the MIUI forum who ended up bricking their devices or damaging their motherboards while trying to repartition).
Then how do these partition apps work?
prahladyeri said:
There are a plethora of apps on the PlayStore that claim to actually "resize" your eMMC partitions. How well do they work? Can you just install it and change your say internal partition from 500MB to 1GB?
To the best of my knowledge, partition tables are kept well hidden and behind lots of complexities on various devices. The repartitioning methods are different on each device and too complex to try out (I know many on the MIUI forum who ended up bricking their devices or damaging their motherboards while trying to repartition).
Then how do these partition apps work?
Click to expand...
Click to collapse
Member this is for the Junior and or new Members of XDA. You have been around long enough to know where to look or ask your questions.
Thread Closed.
I'm new to rooting and installing new roms on android systems, but i work making custom linux and windows systems and optimizing for over a decade.
So, my optimizing spirit is tingling to try everything, but this particular thing is just a question, i'm not intending to actually do it.
When using the terminal on TWRP, i've noted that i could fdisk the internal storage (/dev/mmcblk0) and that i could see all the partitions it had, like system, data, cache and so on.
TWRP and other tools only re-format those partitions with ext4 in order to wipe, so i used 'dd' in terminal to zerofill the ones i knew i could wipe and then formatted then in ext4 (with 'dd if=/dev/zero of=partition').
But i had a bigger question and i couldn't find answer nowhere: What would happen if i actually used dd to zero fill EVERYTHING, the entire /dev/mmcblk0, including the very partition table, every byte on it?
Would the device still enter fastboot mode? Would i still be able to connect it on the fastboot utility and flash a new recovery or do something?
Or, if after zero filling, still on the terminal, if i used fdisk to re-create the proper partitions and then formatted them, could i reboot, re-flash the recovery (once there would be the partition for it) and do an very-deep-clean install?
Not that i think that this has any utility, i just wonder if this would end up rendering the device totally useless, or if the fastboot mode is stored in an ROM chip, like a computer bios is.
Guilherme Franco said:
I'm new to rooting and installing new roms on android systems, but i work making custom linux and windows systems and optimizing for over a decade.
So, my optimizing spirit is tingling to try everything, but this particular thing is just a question, i'm not intending to actually do it.
When using the terminal on TWRP, i've noted that i could fdisk the internal storage (/dev/mmcblk0) and that i could see all the partitions it had, like system, data, cache and so on.
TWRP and other tools only re-format those partitions with ext4 in order to wipe, so i used 'dd' in terminal to zerofill the ones i knew i could wipe and then formatted then in ext4 (with 'dd if=/dev/zero of=partition').
But i had a bigger question and i couldn't find answer nowhere: What would happen if i actually used dd to zero fill EVERYTHING, the entire /dev/mmcblk0, including the very partition table, every byte on it?
Would the device still enter fastboot mode? Would i still be able to connect it on the fastboot utility and flash a new recovery or do something?
Or, if after zero filling, still on the terminal, if i used fdisk to re-create the proper partitions and then formatted them, could i reboot, re-flash the recovery (once there would be the partition for it) and do an very-deep-clean install?
Not that i think that this has any utility, i just wonder if this would end up rendering the device totally useless, or if the fastboot mode is stored in an ROM chip, like a computer bios is.
Click to expand...
Click to collapse
The hardware side of fastboot is typically stored on mmcblk0 somewhere in bootloader, meaning it is in the boot partition which is one of the things you would wipe. This would hardbrick your device, rendering it virtually unrecoverable, with a very slim chance of recovering, if its even possible at all, typically, it isn't possible.
Just stick with the tools already designed to handle any wiping that you need.
Sent from my SCH-I535 using Tapatalk
Droidriven said:
The hardware side of fastboot is typically stored on mmcblk0 somewhere in bootloader, meaning it is in the boot partition which is one of the things you would wipe. This would hardbrick your device, rendering it virtually unrecoverable, with a very slim chance of recovering, if its even possible at all, typically, it isn't possible.
Just stick with the tools already designed to handle any wiping that you need.
Sent from my SCH-I535 using Tapatalk
Click to expand...
Click to collapse
That's interesting, i thought my fear was irrational, but it seems to be the case.
But, why is it like that? Why leave everything you need in an RW memory, while you could use a piece of ROM memory to grant the basic functions and the capability of manipulating the RW one (like a PC BIOS)?
In computers you usually don't need to mind wiping everything you can, your device will still work or will be at least recoverable.
Even screwing BIOS and firmwares in computers and some other devices is something that usually won't render the device unrecoverable. Although they sure can cause a hell lot of headache and may need physical intervention like soldering chips and such, i myself strove to find the correct bios images for certain motherboards and to flash the chips because i didn't have an proper flashing equipment, so i had to build an arduino circuit for that (but i luckily worked with detachable chips).
The only other device i know to be rendered unrecoverable are hard drives if you wipe the firmware stored in platter, as it has the service area, which keeps a big part of all information needed to properly address and read the disk and even the other system tracks spread through the disk, that are also needed to control the head, to read and to correct data errors.
Some of these are written at factory, but others must be writable so the hard drive can take care of itself.
But you'd only be able to mess with these data with proprietary low-level software using specific microcode, zero fill and low-level formatting software can't write on any of these tracks, they can only access LBA addressed tracks.
Guilherme Franco said:
That's interesting, i thought my fear was irrational, but it seems to be the case.
But, why is it like that? Why leave everything you need in an RW memory, while you could use a piece of ROM memory to grant the basic functions and the capability of manipulating the RW one (like a PC BIOS)?
In computers you usually don't need to mind wiping everything you can, your device will still work or will be at least recoverable.
Even screwing BIOS and firmwares in computers and some other devices is something that usually won't render the device unrecoverable. Although they sure can cause a hell lot of headache and may need physical intervention like soldering chips and such, i myself strove to find the correct bios images for certain motherboards and to flash the chips because i didn't have an proper flashing equipment, so i had to build an arduino circuit for that (but i luckily worked with detachable chips).
The only other device i know to be rendered unrecoverable are hard drives if you wipe the firmware stored in platter, as it has the service area, which keeps a big part of all information needed to properly address and read the disk and even the other system tracks spread through the disk, that are also needed to control the head, to read and to correct data errors.
Some of these are written at factory, but others must be writable so the hard drive can take care of itself.
But you'd only be able to mess with these data with proprietary low-level software using specific microcode, zero fill and low-level formatting software can't write on any of these tracks, they can only access LBA addressed tracks.
Click to expand...
Click to collapse
The simple answer would be that the manufacturers don't want you messing with the device to begin with so they don't do anything to make flashing or recovering easier for us.
Sent from my SCH-I535 using Tapatalk
It seems like the only wat to bypass this Trusted Zone sh.. t and android's security is to look back at the very begining of reading, writing bits on disks, and partitions types and diffrent types of storage.
Maybe that way we can create a full backup of the entire system partitions, it must be a way, it must be there some ancient software that can be able to read, write and backup bit by bit.
Example: R Drive Image for Windows.
The problwm will be in recognizing the hardware storage...
Any ideeas ???