[GUIDE] [INFO] The reality of PIT files

[bmadalin]

and in case you missed it, here is the noob question (i've been reading threads for hours can't find the answer): why shoud I repartition, i've flashed a few times upgrading the firmware with odin but never used PIT, am i missing something?

 

[Kops]

Can't thank you enough for the thorough explanation, backed with actual proof.

Great thread!

 

[timelessfahad]

Thanks a million. This has clear many doubts and confusion in my mind.

 

[azzledazzle]

Can't thank you enough for the thorough explanation, backed with actual proof.

Great thread!

+1

Very useful information here, and a much needed thread too !!!
Thankyou for taking the time to explain in detail the meaning of PIT files. it always confused me, and now i understand it all

well done !

 

[seresseran]

and in case you missed it, here is the noob question (i've been reading threads for hours can't find the answer): why shoud I repartition, i've flashed a few times upgrading the firmware with odin but never used PIT, am i missing something?

Simple. Sometimes you make mistakes and mess up partitions. Then your only recovery solution is to repartition.

 

[[Ramad]]

Thanks Ramad. Very useful information for all of us. Many questions are gone from my mind, but

" Then How the guys at samfirmware decide about the pit file when they release a firmware ?"

As you know, the firmware table at samfirmware points us different pit files for different firmwares. WHY? According to what?

I doubt that the guys at samfirmware do know much about when to use a pit file. They write that if the firmware is a 3 file firmware then 512.pit is to be used, but if the firmware is a 1 file firmware then 803.pit is to be used without checking re-partition...that is not correct at all.

A pit file should only be used when re-partitioning is needed, the device already have a copy of the previously used pit file stored at the second sector at the ROM(please see ROM partitions at post #1), when re-partition is not checked then Odin retrieves the information from that sector and flashes the device according to it, even if you did choose a different pit file than the one stored at the ROM.

I believe hardcore had preciously mentioned about the increase in the usable space after lagfix is applied.

[Ramad], were you on ext4, or rfs? Maybe try the experiment on both file system?

Anyway, excellent information.

Sent from my GT-I9000

All the testing was performed on stock firmware with RFS, and the idea is to provide information on pit files and the device behaver with no changes. If I would be using a different file-system then that will be investigating a moded firmware, although I can confirm that using a lagfix does retrieve the missing space, and that is related to how a lagfix works, by copying the files on /system to the internal SD-card, formatting /system and then copying the files back, when a lagfix formats /system, then it will be formatted as a partition not as a space, this is why whole system partition will be usable after that.

The reason that you don't see increased space in /system is because the usable size of that partition is recorded in the ROM. If you apply a lagfix to the partition with 513.pit, you will see that the usable space is increased because a new partition is created.

The reason for the increased space in 513.pit, the /system in certain Asian roms (such as DXJPA) needs to be larger to contain the large amount of CSC.

I did not mention DXJPE because it's an exception, it will only except 513.pit and it will make the whole partition usable with more than 39MB of free space, all of that is on stock RFS. When doing the math then only around 258MB of /system is used by data copied to it during installation...so saying that DXJPE is a big firmware compared to other firmwares is not the case here. You could be pretty much right about the usable size of /system partition is recorded in the ROM.

Interesting discussion. Just a thought - is it possible the 'missing' space is being used for security or data integrity? How about reserved for possible future defective memory blocks?

Sent from my GT-I9000M using XDA App

This is what we don't know...I hope so, releasing and using 803.pit or 513.pit can have a meaning then.

and in case you missed it, here is the noob question (i've been reading threads for hours can't find the answer): why shoud I repartition, i've flashed a few times upgrading the firmware with odin but never used PIT, am i missing something?

You will never need to use a pit file while flashing using Odin unless you want to re-partition...the pit file is already there for Odin to read from the ROM.

 

[g00ndu]

I doubt that the guys at samfirmware do know much about when to use a pit file. They write that if the firmware is a 3 file firmware then 512.pit is to be used, but if the firmware is a 1 file firmware then 803.pit is to be used without checking re-partition...that is not correct at all.

A pit file should only be used when re-partitioning is needed, the device already have a copy of the previously used pit file stored at the second sector at the ROM(please see ROM partitions at post #1), when re-partition is not checked then Odin retrieves the information from that sector and flashes the device according to it, even if you did choose a different pit file than the one stored at the ROM.



All the testing was performed on stock firmware with RFS, and the idea is to provide information on pit files and the device behaver with no changes. If I would be using a different file-system then that will be investigating a moded firmware, although I can confirm that using a lagfix does retrieve the missing space, and that is related to how a lagfix works, by copying the files on /system to the internal SD-card, formatting /system and then copying the files back, when a lagfix formats /system, then it will be formatted as a partition not as a space, this is why whole system partition will be usable after that.



I did not mention DXJPE because it's an exception, it will only except 513.pit and it will make the whole partition usable with more than 39MB of free space, all of that is on stock RFS. When doing the math then only around 258MB of /system is used by data copied to it during installation...so saying that DXJPE is a big firmware compared to other firmwares is not the case here. You could be pretty much right about the usable size of /system partition is recorded in the ROM.



This is what we don't know...I hope so, releasing and using 803.pit or 513.pit can have a meaning then.



You will never need to use a pit file while flashing using Odin unless you want to re-partition...the pit file is already there for Odin to read from the ROM.

Thanks, [Ramad] for the explanation. Glad that we know a lot more now.

Sent from my GT-I9000

 

[pawitp]

I did not mention DXJPE because it's an exception, it will only except 513.pit and it will make the whole partition usable with more than 39MB of free space, all of that is on stock RFS. When doing the math then only around 258MB of /system is used by data copied to it during installation...so saying that DXJPE is a big firmware compared to other firmwares is not the case here. You could be pretty much right about the usable size of /system partition is recorded in the ROM.

The thing is, when you're flashing a ROM, you're flashing a file system. And when it comes to size, there are 2 sizes — partition size and file system size. The file system size cannot be larger than the partition size but can be (but not usually) smaller than the file system size. The file system size is determined to be equal to the partition size where that file system was created. What's happening here is that the file system of most ROMs are created against 512.pit and thus is smaller than the partition size when flashed on 513.pit. The file system does not realize that it is on a partition larger than when it was created and thus the additional space cannot be used.

What's happening when a lagfix is applied is that the files of /system are copied over to the SD card and a new file system is created which naturally matches the size of the partition, thus the increased usable space. The files of /system are then copied back to the new partition.

I still believe that the DX-series is larger than most other ROMs. When you said that "only around 258MB of /system is used by data copied to it during installation", did you include the size of the CSC which is copied to /system during first boot in recovery after a firmware flash?

 

[[Ramad]]

I still believe that the DX-series is larger than most other ROMs. When you said that "only around 258MB of /system is used by data copied to it during installation", did you include the size of the CSC which is copied to /system during first boot in recovery after a firmware flash?

Sorry about what I wrote earlier, that was misleading as I could pretty much have been using a deodexed firmware, 258MB cannot be right when the the stock factoryfs.rfs alone is 254MB in size, they say that a picture do say a thousand words...

In theory 803.pit with 287MB should be enough but DXJPE can't be installed using 803.pit file, /system in RFS format and the CSC files are installed.

 

[pawitp]

You can't flash DXJPE with 803.pit because when the file system size is larger than the partition size, ****s happen.

 

[[Ramad]]

You can't flash DXJPE with 803.pit because when the file system size is larger than the partition size, ****s happen.

What do you mean?
803.pit file system partition size is 287.5MB, DXJPE system data size including CSC files is 276.2MB, how is 276.2 bigger than 287.5MB? I guess that the pit thing is a bit confusing..

 

[pawitp]

When you flash /system, you're flashing factoryfs.rfs which contains a file system. In the header of that file, the amount of usable space is recorded (which I call file system size). If the recorded amount of usable space is less that the partition size, you will see unusable space. However, if the recorded amount of usable space is more than the partition size, the system will either error out or, more dangerously, invade the data of the next partition when a space beyond the partition size (but within the file system size) is requested.

 

[pascaliut]

your phone has been partionned out of the box. you donot need to do it again except if you want to completly format your phone. and here you can pick a pit file do tell how you will format your phone.

Sent from my GT-I9000 using XDA App

 

[DamianGto]

Funny tread.
OP still don't understand how pit files work and how the files is he is flashing.
The test he did just show the lack of knowledge.
We did make a tread about pit file and how they work. That's old news now.
OP don't seem to understand how the file system works and people in has pointed it out for him.

So some real facts.
Pit file is a file that tell how the partitions shall be. Pit=Partition Information Table.
On that you put a file system.
When you flash a firmware you basically flash premade file system image. These image has fixed file space.
When you for change the filesystem you use the whole size of the partition and put the files back. That's why you get more space after you change the file system. Also different file system do take different space for the information that's file system use. That's can free up more space or lower the space left on the partition.





**DamianGTO ultimate kernel v1.1 * 600Hz * 350MB RAM * OC/UV * 1200MHZ**

 

[[Ramad]]

When you flash /system, you're flashing factoryfs.rfs which contains a file system. In the header of that file, the amount of usable space is recorded (which I call file system size). If the recorded amount of usable space is less that the partition size, you will see unusable space. However, if the recorded amount of usable space is more than the partition size, the system will either error out or, more dangerously, invade the data of the next partition when a space beyond the partition size (but within the file system size) is requested.

Your last post did not picture this but was talking about actual size and usable size. However, I find what you write now about factoryfs.rfs file headers more interesting.
This is what I think too after having changed all the files in DXJPE except factoryfs.rfs to see if any other file/image had an influence in making the whole /system partition space available, well that was not the case, as it appeared to me that factoryfs.rfs in the case of DXJPE was the only responsible factor for that.
We still can't say that what makes the changes is in factoryfs.rfs header is a fact until we find the area or the code-lines in factoryfs.rfs that proves it. Not that I disagree with you, because I do agree with you as I wrote earlier, but it is still only a theory until we have the proof.

 

[cicciocant]

A pit file should only be used when re-partitioning is needed, the device already have a copy of the previously used pit file stored at the second sector at the ROM(please see ROM partitions at post #1), when re-partition is not checked then Odin retrieves the information from that sector and flashes the device according to it, even if you did choose a different pit file than the one stored at the ROM..

It isn't true. For me.
If you check re-partition then odin write the pit file in /dev/block/bml2 partition and use it for write size of partition in to device.

If you don't check re-partition then odin use pit file for write size of partition but it don't write the pit file in /dev/block/bml2 partition.

Sorry for my bad english.

 

[[Ramad]]

It isn't true. For me.
If you check re-partition then odin write the pit file in /dev/block/bml2 partition and use it for write size of partition in to device.

If you don't check re-partition then odin use pit file for write size of partition but it don't write the pit file in /dev/block/bml2 partition.

Sorry for my bad english.

What is not true?
Please flash a firmware without pit and without re-partition and tell me your results please, then tell me how Odin could do that when you did not choose any pit file...beside that tell me about this line and what it does mean when no pit has been chosen:

I have marked the lines for you...

Now flash a firmware with 512.pit while re-partitioning, go to Applications > Task Manager > Summary and check the size of Personal data which is /dbdata, it should be 127MB, then flash a firmware with 803.pit without re-partitioning and check Personal data....now tell me why is it still 127MB and according to what you did write then it should be 117MB?

I will be waiting for your results, please post them when you are done

 

[tonymy01]

I have never used a pit file in my dozen or so flashes I have done with odin.
I can imagine the difference in partition size vs filesystem size is because the filesystems are pre-packed into rfs images that are simply "dd" to the partition when the firmware is upgraded/written to the phone. So the filesystem size is approx the rfs size. In the linux world, there are tools to add this "unused" partition space back to the filesystem (easy if it is at the end of the filesystem on the hdd), I wouldn't imagine it would be all that difficult to write a tool to add the unused space to an rfs partition..
I suppose there is larger system partition than needed so a phone can be upgraded to a more feature rich system (e.g 2.1 to 2.2) to allow for a bit more, while not having to rewrite the whole partition table and therefore trashing all the user data etc in the other partitions.

Sent from my GT-I9000 using XDA App

 

[dakost]

Thanks for the explanation. Interesting.

So how does one find out what pit is his galaxy s on? Just checking the size of /dbdata?

I've never needed to repartition and use a pit file.

 

[AllGamer]

this GUIDE is awesome, it should be in DEV section