Database Info

[Q] Hboot vs. /Cache size

Hi all.
I am curious about the differences in the Engineering bootloaders that we have for our devices (0.98.xxxx, 6.xx.xxxx, 2.00.2002) in terms of partitioning.
So I would like to gather some statistics from the you (users in this forum) about the size of your /cache partition and the bootloader (hboot) that you are using to see is there a difference.
For the hboot version you just have to reboot to bootloader from the power menu
for the size of the /cache partition use the Android Terminal Emulator (free from the Market) and type:
Code:
df
then look at the row that is written /dev/block/mmcblk0p27 - the size is next to it (under the 1K-blocks column)
Thank you in advance!

/cashe is 302356K total
My hboot is stock (0.98.0002)

my cache is 138mb using new ENG HBOOT 2.00.2002

HBOOT 2.00.2002 (The leaked one from about a month ago).
150mb/138mb free.

i have the same cache as u but cannot see the lib partition anywhere after updating to the new hboot. can u?

Eclipse_Droid said:
i have the same cache as u but cannot see the lib partition anywhere after updating to the new hboot. can u?
Click to expand...
Click to collapse
I think this works only with the leaked Deseire S Sense 2.0 [2.3.5], ported by proxuser and its kernel. Because this bootloader appeared in the forum for the new kernel users. I am not aware whether any of the custom ROMs supports that kernel, so maybe this hboot 2.00.2002 is useful only for the leaked stock roms (proxuser's and the new OTA one). Just my assumption...
P.S.: Thank for the posted so far!. Looks fro your posts that the stock bootloader offers the most cache space. Looking for other inputs

I'm running the new HBOOT 2.xx.xxxx and I'd like a decent in lay-mans terms explanation of where the 150Mb that CACHE has lost has gone to, I believe LIB but I can't see a LIB partition? So is it being used or will it be used....someone please explain? I've read some attempted explainations but I'm afraid to say that I'm still not happy that I completely understand - I also believe that this is a particular question that many other users would appreciate an answer to.
Code:
$su
# df
/dev: 313160K total, 64K used, 313096K available (block size 4096)
/system: 562404K total, 493304K used, 69100K available (block size 4096)
/data: 1184268K total, 417700K used, 766568K available (block size 4096)
/cache: 146124K total, 4252K used, 141872K available (block size 4096)
/mnt/asec: 313160K total, 0K used, 313160K available (block size 4096)
/mnt/obb: 313160K total, 0K used, 313160K available (block size 4096)
/app-cache: 8192K total, 0K used, 8192K available (block size 4096)
/data/DxDrm/fuse: Permission denied
/mnt/sdcard: 31322160K total, 7923328K used, 23398832K available (block size 16384)
/mnt/secure/asec: 31322160K total, 7923328K used, 23398832K available (block size 16384)
/system/etc/virtuous_oc: 313160K total, 24K used, 313136K available (block size 4096)
#
EDIT: changed CACHE back to ext4 so altered numbers for CACHE to reflect this!
Swyped from my Desire S using XDA Premium

Eclipse_Droid said:
i have the same cache as u but cannot see the lib partition anywhere after updating to the new hboot. can u?
Click to expand...
Click to collapse
Btw have you flashed the PG88IMG that is attached in the hboot 2.002.002 guide?? This is your lib partition, but it works only on Sense based ROMs or even only Sense Stock ROMs (like the one from proxuser)?.
@ben_pyett
+1. This was the main reason for starting this thread. Because in my desire to be up to date I flashed all the new stuff that came around, but now I start to question myself is this really necessary...

amidabuddha said:
Btw have you flashed the PG88IMG that is attached in the hboot 2.002.002 guide?? This is your lib partition, but it works only on Sense based ROMs or even only Sense Stock ROMs (like the one from proxuser)?.
@ben_pyett
+1. This was the main reason for starting this thread. Because in my desire to be up to date I flashed all the new stuff that came around, but now I start to question myself is this really necessary...
Click to expand...
Click to collapse
Just released the somehow my CACHE had become ext3? no idea when or how this happened so convered to to ext4 using 4EXT recovery and reformatted.
So I altered the numbers in the above post to reflect changes this made.
I used a different method as I was S-OFF via XTC Clip! [GUIDE] XTC-Clip users guide to new HBOOT 2.00.2002

Its depends on the rom and the install script.
Proxusers OTA is compatible with the old HBOOT, so it doesnt use the new lib partition.
If you flash the untouched version you have the lib partition.

caravanquello said:
Its depends on the rom and the install script.
Proxusers OTA is compatible with the old HBOOT, so it doesnt use the new lib partition.
If you flash the untouched version you have the lib partition.
Click to expand...
Click to collapse
Yep, you are right. I meant the early proxuser's versions that I was happy to use up to v8 (IMO very good work). But then I gave up on Sense and not regretting a bit. Anyway according to your explanation my logic is right and this 2.00.2002 hboot is only useful for HTC ROMs, although modified by the devs here, but is pointless to use with ROM's that are not supporting it i.e. most of them.
@ben_pyett
I think that the new radio installation is messing with the cache partition, because I had the "cache_log" error after flashing it, also I am reading a lot of feedbacks from users that had to restore/reformat this partition after flashing the radio due to "not enough space" error when installing apps from the Market.

amidabuddha said:
@ben_pyett
I think that the new radio installation is messing with the cache partition, because I had the "cache_log" error after flashing it, also I am reading a lot of feedbacks from users that had to restore/reformat this partition after flashing the radio due to "not enough space" error when installing apps from the Market.
Click to expand...
Click to collapse
I possibly can agree with that as I also encountered that problem with the market after installing both the latest radio and being on latest HBOOT.
Although market space error was simply resolved by a CACHE wipe, although I'm still unsure what particular process or step put my CACHE to ext3?

ben_pyett said:
I possibly can agree with that as I also encountered that problem with the market after installing both the latest radio and being on latest HBOOT.
Although market space error was simply resolved by a CACHE wipe, although I'm still unsure what particular process or step put my CACHE to ext3?
Click to expand...
Click to collapse
exactly same thing happened to me too. just formatted back to ext4. byy the way i am now back on old ENG HBOOT and i have got my full 300mb cache partition back

Eclipse_Droid said:
exactly same thing happened to me too. just formatted back to ext4. byy the way i am now back on old ENG HBOOT and i have got my full 300mb cache partition back
Click to expand...
Click to collapse
Can you please explain how you did this, because I am also on the old bootloader but my /cache is still halved (150 MB)??
EDIT: when I reboot in the Recovery my /cache is exactly 300 MB, but the "df" command in the Terminal is showing 150 MB?? Is this the same in your case?
EDIT2: I have wiped the cache and now it shows 300 MB in the terminal. Hooray!
Just to confirm my assumption that the radio is the reason for this mess. What I did to the current state was:
1) I think I was the first one that flashed it over 2.00.2002 (almost immediately after it was posted, even before the ben_pyett's first question on the OTA radio thread, and I stuck with the famous "cache_log" error. I was scared that my eMMC is gone. So I reflashed RUU with the intention to go to the repair center with the stock hboot, etc.
2) then I saw that my system is fine (oh how happy I was) I used the revolutionary tool
3) then I flashed the old ENG HBOOT 0.98.2000
4) then I flashed the new OTA radio again
5) then I flashed the CM7 Nightly, Tiamat kernel and the GApps
6) after booting the ROM I installed the 4EXT recovery
7) after that I rebooted in the Recovery and had again the "cache_log" error, but I was calm this time and just formatted it as ext4
8) then I have noticed that my /cache is 150 MB???
so only thing that I have made extra than prevously was the new radio. CM has no customized partitioning and for me the only cause of the can be this Radio...

amidabuddha said:
Can you please explain how you did this, because I am also on the old bootloader but my /cache is still halved (150 MB)??
EDIT: when I reboot in the Recovery my /cache is exactly 300 MB, but the "df" command in the Terminal is showing 150 MB?? Is this the same in your case?
EDIT2: I have wiped the cache and now it shows 300 MB in the terminal. Hooray!
Just to confirm my assumption that the radio is the reason for this mess. What I did to the current state was:
1) because I was stuck with the famous "cache_log" error and I think I was the first to flash it over 2.00.2002 (almost immediately after it was posted, even before the ben_pyett's first question on the OTA radio thread, I was scared that my eMMC is gone. So I reflashed RUU with the intention to go to the repair center with the stock hboot, etc.
2) then I saw that my system is fine (oh how happy I was) I used the revolutionary tool
3) then I flashed the old ENG HBOOT 0.98.2000
4) then I flashed the new OTA radio again
5) after that I had again the "cache_log" error in the recovery, but I was calm this time and just formatted it as Ext4
5) then I flashed the CM7 Nightly, Tiamat kernel and the GApps
6) then I have noticed that my /cache is 150 MB???
so only thing that I have made extra than prevously was the new radio. CM has no customized partitioning and for me the only cause of the can be this Radio...
Click to expand...
Click to collapse
interesting!
everything you experienced with the cant mount errors after flashing the new radio happened to me too! i too feared i had fried the emmc chip! I am still on new radio now and everything is fine after reformatting the cache partition.
In answer to your question i believe it MUST be the new radio trying to alter partition of the cache. This would explain why it is giving you the same "cant mount cache" error as it gives when flashing new HBOOT. Something in the installation of the radio package must be trying to split the partition.
Anyway, im happy now! and by the sounds of it u are too, and have pretty much the same base setup as i do
OLD ENG HBOOT ALL THE WAY!!

@ben_pyett
Just an addition to my previous assumption.
I doubt that the Stock ROM natively supports ext4. So if the radio is altering somehow the /cache partition it of course is designed to search and manipulate an ext3 type partition (most probably this is the cause of the error). When you have reformatted, it was restored as it was labeled by the radio script - as an ext3. So the restoration solved your Market problem, you just noticed the ext3 type later.
Sent from my HTC Desire S using XDA App

amidabuddha said:
@ben_pyett
Just an addition to my previous assumption.
I doubt that the Stock ROM natively supports ext4. So if the radio is altering somehow the /cache partition it of course is designed to search and manipulate an ext3 type partition (most probably this is the cause of the error). When you have reformatted, it was restored as it was labeled by the radio script - as an ext3. So the restoration solved your Market problem, you just noticed the ext3 type later.
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
this is a very good point! but why is it only changing the cache partition and not the rest?

Eclipse_Droid said:
this is a very good point! but why is it only changing the cache partition and not the rest?
Click to expand...
Click to collapse
I think that at this point already some of the devs has to clarify further
Edit: now a conversation with Nexx in his CM7 thread comes to me. He said that the new partition (lib) is taking up space from the /cache not from /system (which fact is verified by the results in this thread). So maybe the script is checking for the "properly" mounted partitions and when is not finding the lib.img is trying to remount or to force reformat/rebuild that is causing the corruption. Just a theory of mine but linux is working quite straightforward as far as I know
Sent from my HTC Desire S using XDA App

amidabuddha said:
I think that at this point already some of the devs has to clarify further
Edit: now a conversation with Nexx in his CM7 thread comes to me. He said that the new partition (lib) is taking up space from the /cache not from /system (which fact is verified by the results in this thread). So maybe the script is checking for the "properly" mounted partitions and when is not finding the lib.img is trying to remount or to force reformat/rebuild that is causing the corruption. Just a theory of mine but linux is working quite straightforward as far as I know
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
i guess this could be true! either way, we are both running new radio now without any issues
just a bit annoying having to go through this process before you have it working

Well done gentlemen!
It's good to at least get to the bottom of why the file system ext3->ext4 conversion occurred.

[Q] How to resize/recreate /system and /data partitions?

With all the lighter custom ROMs we have today, the default huge /system partition we have in the O3D is a waste of space. Same with the /data partition. For those who don´t know, both /system and /data (and other smaller ones) are actual internal SD Card space!
That´s why we have LG specs saying we have 8GB of internal flash storage, when in fact we have just 5.5GB available.
So my question is: is there a (safe) way to wipe all internal SD partitions and then recreate them with more appropriate sizes, earning back all the wasted space?
Thanks a lot!

Marcovecchio said:
With all the lighter custom ROMs we have today, the default huge /system partition we have in the O3D is a waste of space. Same with the /data partition. For those who don´t know, both /system and /data (and other smaller ones) are actual internal SD Card space!
That´s why we have LG specs saying we have 8GB of internal flash storage, when in fact we have just 5.5GB available.
So my question is: is there a (safe) way to wipe all internal SD partitions and then recreate them with more appropriate sizes, earning back all the wasted space?
Thanks a lot!
Click to expand...
Click to collapse
Have you read about data2ext? I think it would be a very good solution to us.
Sent from my LG-P920 using XDA App

Thanks for the reply, ThiaiZ!
However, I think I´m looking for something different: as far as I know, data2ext changes the /data partition pointer to external memory (SD Card), so the original /data partition will never be used by the OS, and it´s space will be wasted, right?
I would like to find a way to get this wasted space back! If we could repartition /system, /data, /cache, to smaller sizes, we would have more storage space for stuff on the internal SD. Does it make sense? Thanks!

Well, since I had no solutions here, I would like to post some examples of this for other phone models:
MyTouch 3G Slide - http://forum.xda-developers.com/showthread.php?t=893706
LG GT540 - http://forum.xda-developers.com/showthread.php?t=1171531
The MyTouch 3G Slide thread is particularly good because it explains in detail how to check the partition sizes, and shows how much space is wasted on the /system partition.

Marcovecchio said:
Well, since I had no solutions here, I would like to post some examples of this for other phone models:
MyTouch 3G Slide - http://forum.xda-developers.com/showthread.php?t=893706
LG GT540 - http://forum.xda-developers.com/showthread.php?t=1171531
The MyTouch 3G Slide thread is particularly good because it explains in detail how to check the partition sizes, and shows how much space is wasted on the /system partition.
Click to expand...
Click to collapse
Don't we have to be s-off to be able to resize the partitions ?
I did it a lot on my HTC Desire.
BTW do you have any idea in which block data and sd-ext are mounted on our device ?

I believe the S-OFF flag exists only in HTC devices. I read that somewhere here, at XDA. The guy seemed to know what he was talking about, and he said LG never implemented any kind of protection like S-ON / S-OFF.
About the block names, I believe you can list the blocks and the partition names they´re mounted as, with the "df" command. I know almost nothing about Linux, and even less about how Android manage it´s partitions, but that would be nice to be able to tweak their sizes...

LG GT540's partitions can easily be resized by flashing an MBN file. Don't know if this phone can get that done too
http://forum.xda-developers.com/showthread.php?t=1171531

Don't try resizing partitions.
You'll brick your phone.

[Q] Resize internal partitions

Hi,
This has been asked many times before with no real solution that applies to different devices.
I'm running out of space on my /system partition and can't install any more apps even though I don't have that many installed.
I want a way to re-size the Android partitions manually to whatever size I want. Or just delete all current partitions and create new ones.
How do I do that? Is there any GUI partitioning tools similar to the ones available for Windows?
I don't want to move files from /system to another partition. I want to change the partition size.
My current /system partition:

For what reason are you moving apps to /system? You can't install them there, you have to push/move them there, installs go to /data. So keep them in /data, where they're installed by default. You have tons of space available there.
Partition table (start addresses and sizes) is hard-coded in bootloader, and can be redefined in kernel boot parameters (in this case recovery needs to be recompiled with the same parameters too, otherwise it won't write to the same partitions the kernel will read from). You're welcome to hack any of those. As you could probably understand from this paragraph, I wouldn't expect having GUI tools for that.

Thanks for the reply.
I'm not trying to move apps to /system. I thought apps are installed there by default because every time I try to install a new app it gives me an error message saying that there is not enough space on /system.
Now I know that apps are not installed in /system.
I just need more space in /system so I can install new apps without any errors.
What can I do to get more space on /system partition? Can I replace the bootloader?
I don't have any Android programming experience. I probably need something that is available out there to do the job.

In stock form, you shouldn't even have write permissions to /system. Nothing should be ever written there, and it can be 99.99999% utilized - there shouldn't be any free space left for anything, it shouldn't normally be used.
If you're getting that error when trying to install an app - you need to check what's reporting the error. It's not a "real" error, it means there's something wrong with your phone.

Try wiping cache partition from recovery...does this make any difference?
Jack is correct.
Swyped from my DesireS

refer to this
if this may help you http://forum.xda-developers.com/showthread.php?t=1959691
:highfive:

mayank88288 said:
refer to this
if this may help you http://forum.xda-developers.com/showthread.php?t=1959691
:highfive:
Click to expand...
Click to collapse
Way to bump a year old thread :thumbup:
“I'm bad and I'm going to hell, and I don't care. I'd rather be in hell than anywhere where you are. ”*―*William Faulkner

storage issue

Hello, I have this phone (8gb) since August and never noticed how much storage I have until now because it started notifying me storage was full. Well, it says total space is 4,53gb and without /system 3,60. So my question is, where is the 4gb of storage that I don't see? I was hoping it was occupied by /system but it is not. We're talking about a half of the storage and it's unbelievable that I cannot use at least 5 of the 8 I've payed for.
Any help would be very appreciated!

4.53 gb is your /data partition(user apps and data are stored here), other space is used in /system partition where all system files are located.

Is there a way to resize the partitions?

isavoro said:
Is there a way to resize the partitions?
Click to expand...
Click to collapse
it was possible to resize partitions in many phones and there are also apps available on playstore for it. but you should reset it to default before flashing any rom. :/

And do you think reducing /system may be a problem?

isavoro said:
And do you think reducing /system may be a problem?
Click to expand...
Click to collapse
when I was using stock, my system partition was filled by 1.5gb from 2.19gb. there is still some space there but you shouldn't reduce it because it will get filled over time with app updates. and there will be problem with ota updates if you resize it.

Why is the OS (System) size different for different storage variants of the same device model?

I have seen that the space occupied by 'System' is different for different storage sizes of the same device.
My Samsung Galaxy S22 Ultra shows space occupied by system as over 50 GB. Mine is the 512 GB variant (Snapdragon). While I don't remember how much it was out of the box, but it has been somewhere in that region throughout.
But the space occupied by S22U 256 GB variant is much lower, at around 30 GB for the same region.
{
"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"
}
Can someone explain why this is different?
In this context, Samsung's OneUI is probably the most bloated version of Android. Even though there is some explanation (about 7% conversion loss) as to why System on Samsung devices shows a very high use of storage space (it apparently includes the 7% conversion loss), it still doesn't explain why the System size is substantially different between different storage variants of the same device.
References:
Not True- 60 GB OS Occupy on the Samsung Galaxy S23 Ultra
You may already know about 60 GB OS Occupy on the Samsung Galaxy S23 Ultra from popular News Sites. But that is not accurately correct. The claim that
www.androidinfotech.com
One UI 5.1 bloatware does NOT take up 60GB storage on the Galaxy S23 series
It turns out One UI 5.1 bloatware does not take up 60GB system storage on the Galaxy S23 phones. Here's an explanation.
www.androidauthority.com

download the ROM from samfw or samloader, extract it and see what is inside. I bet even when converted into raw partition images the system is around 4 GB only. therefore what you mean with System is actually userdata or something different.

aIecxs said:
download the ROM from samfw or samloader, extract it and see what is inside. I bet even when converted into raw partition images the system is around 4 GB only. therefore what you mean with System is actually userdata or something different.
Click to expand...
Click to collapse
User files, app data, etc. are shown separately.

check the output of df what is the total size of system partition. check space occupied on userdata partition.
Code:
df -h /
df -h /data

aIecxs said:
check the output of df what is the total size of system partition. check space occupied on userdata partition.
Code:
df -h /
df -h /data
Click to expand...
Click to collapse
My device isn't rooted. Not sure if these terminal commands would work.
Doing a bit of math, here are the numbers:
The 7% computational difference means:
For 512 GB variant, about 36 GB is included in the System classification, which means the OS itself is only about 14 GB, which is along expected lines.
For 256 GB variant, 7% is about 18 GB, so if Storage Analysis shows System as occupying about 32 GB, this will confirm the OS itself is only about 14 GB, which is same as above. Someone with a 256 GB variant would be able to confirm this.
Likewise, the 128 GB variant should show System as occupying 23 GB and 1 TB variant should show System as occupying 86 GB.
Hopefully people with these storage variants can confirm this.
Samsung should ideally provide more details (breakdown) on what makes up the space shown against System as OS Files and Others.

the df cmd doesn't need root. you could easily figured out from any terminal emulator.

I checked this ROM and the super partition is 12G only.
https://samfw.com/firmware/SM-S908U/TMB/S908USQU2CWAI
Doing a bit of math, here are the numbers:
12G - 9.3G = 2.6G reserved
the system partition is only 6.1G (haven't checked f2fs file system, it's less). so obviously what you see as System is actually stored on userdata partition. I assume the ROM is the same for all variants of storage 128/256/512G, so the system partition is therefore also the same size.
Code:
[email protected]:/mnt/c/Android/Backup/SM-S908U/AP_S908USQU2CWAI_S908USQU2CWAI_MQB61793398_REV00_user_low_ship_MULTI_CERT_meta_OS13/super$ ls -lh
total 9.3G
-rwxrwxrwx 1 ubuntu ubuntu 21M Feb 13 21:21 odm.img
-rwxrwxrwx 1 ubuntu ubuntu 1.1G Feb 13 21:21 product.img
-rwxrwxrwx 1 ubuntu ubuntu 6.1G Feb 13 21:13 system.img
-rwxrwxrwx 1 ubuntu ubuntu 236M Feb 13 21:21 system_ext.img
-rwxrwxrwx 1 ubuntu ubuntu 1.8G Feb 13 21:18 vendor.img
-rwxrwxrwx 1 ubuntu ubuntu 53M Feb 13 20:58 vendor_dlkm.img
btw the 7 % "loss" isn't about occupied space at all, it's simply the "difference" between GB <=> GiB (but it's the same size only different unit)
1000^3 (GB) Gigabyte != 1024^3 (GiB) Gibibyte
https://www.wikipedia.org/wiki/Gigabyte
In other words your phone comes with 512 GB = 476.8 GiB storage. and that marketing naming is same for each and every storage we buy, be it pendrive, MicroSD card or HDD disk drive, not a Samsung thing...

aIecxs said:
I assume the ROM is the same for all variants of storage 128/256/512G, so the system partition is therefore also the same size.
Click to expand...
Click to collapse
That's true. This question arose because the built-in storage analyzer shows different values for different storage variants of the same device (same region).
aIecxs said:
btw the 7 % "loss" isn't about occupied space at all, it's simply the "difference" between GB <=> GiB (but it's the same size only different unit)
Click to expand...
Click to collapse
Yes, it's just a question of units.
The value shown against System is basically the unaccounted difference, which is a mathematical computation of the total storage size minus the sum of all other allocations (classifications).

Okay, think I got it. I had to read whole thread including links again twice...
so what they claim is basically
- Samsung is mixing up different units GB - GiB
- System is not even sum of existing files, but
- System is just calculated by subtracting all the non-system files (rest)
or in other words, the storage app is lying. whoever has coded this.
still I think 20 G is too much compared to 6 G system partition, maybe that is dalvik ART cache of extracted system apks (and their respective apps data) counted all together.
someone with rooted device should count all system files on userdata partition to clarify. the tool already comes with toybox du

@TheMystic Find attached the partition table of the S22U taken from the PIT file. All partitions except /userdata are summarized as "Android OS". The /userdata starts at block 3.574.272 and ends with the last free adress block. With a block size of 4K /userdata starts at 14.640.218.112 byte (13,6GiB, which is the occupied storage by Android OS)
TheMystic said:
References:
Not True- 60 GB OS Occupy on the Samsung Galaxy S23 Ultra
You may already know about 60 GB OS Occupy on the Samsung Galaxy S23 Ultra from popular News Sites. But that is not accurately correct. The claim that
www.androidinfotech.com
One UI 5.1 bloatware does NOT take up 60GB storage on the Galaxy S23 series
It turns out One UI 5.1 bloatware does not take up 60GB system storage on the Galaxy S23 phones. Here's an explanation.
www.androidauthority.com
Click to expand...
Click to collapse
Taken from 2nd URL:
You always lose about 7% of storage marketed by manufacturers due to conversion losses.
Samsung and some other OEMs choose to hide lost space under the system storage.
Click to expand...
Click to collapse
That's not correct. You can't loose storage due to conversion. If someone runs 1 mile and another one 1,609 km then nobody runs more than the other. Loss of storage would mean 512GB are converted into 476,84GiB and then turned into 476,86GB. That would be indeed a real loss but it's incorrect.
There's also no lost space. The first 256 and the last 34 blocks (512 byte) are reserved for the GPT. Then your bootloader begins at block 256 and the last partition has to end at (last block - 34). Only the single partitions have a rest of unused space at the end. But that's a few kb and quite normal.
The most informations inside the 1st link are nonsense...
Starting with this
1,073,741,824
Click to expand...
Click to collapse
Sorry, that's not a number when using more than one comma.
In binary, 1GB equals 1,073,741,824 bytes, approximately 238.4GB in decimal units for a 256 GB
Click to expand...
Click to collapse
Awesome!! The official binary unit for GB is GiB. Then 256GB are 238,4GiB (<= and this is the binary and not the decimal unit!!).
From the mentioned arstechnica.com page:
Several users report the phone uses around 60GB for the system partition right out of the box.
Click to expand...
Click to collapse
From that point I refused to read any further.
How can a partition on a physical storage become bigger without changing the size of any other partition?
Or how does the stored data on a partition effects the entire amount of the available storage? When I create a 10GB partition on a 100GB physical storage I've a second one of 90GB. No matter what I stored on the 10GB the other is still 90GB. So, the size of /system is always the same!
Back to the 1st link:
The amount of storage space used by the Android system on the Galaxy S23 series is about 20 GB, not 60 GB, as previously reported. This is still a lot of storage, but not as much as reported in the system settings. The additional storage is mainly due to pre-installed apps, including core Google system apps replicated by Samsung. However, it is possible to uninstall most third-party pre-installed apps.
Click to expand...
Click to collapse
I love this guy! Pre-installed apps are called system apps (mostly) because their APK is saved on a system partition. Since those partitions are r/o we can't uninstall them. But if we could, it won't turn any byte on your device into an usuable for you. It's still a system partition mounted r/o and already summarized as Android OS in your storage overview.
Next thing is that neither system apps nor any bloatware (however, who should say an app is bloatware? Should Android decide it on its own "Oh yeah, this app is definitely bloatware! Categorize it as "System" storage, please") could occupy storage as "System". On /data partition it's determinated that the paths ~/app, ~/data and ~/user_de are the OS' app directories. All entries are summarized as "Apps" and that's it.
Additionally, available storage space and updates to the Android operating system can also impact the size of the Android OS on the Galaxy S23 Ultra.
Click to expand...
Click to collapse
No, they can't. If they are stored on your device, then it will be on /cache. Since Samsung is still using A-only partitioning scheme an OTA-update requires to be installed from recovery. But you can't access /data from your stock recovery and it wouldn't make any sense to store the update on it.
alecxs said:
maybe that is dalvik ART cache of extracted system apks
Click to expand...
Click to collapse
Those files are max. 1GB. Only system apps without any updates need /data/dalvik-cache/. The updated ones store their APKs and the odexed Java code in /data/app. Furthermore the libraries and some other storage occupying stuff from the APKs are not part of the dalvik-cache.

WoKoschekk said:
You can't loose storage due to conversion.
Click to expand...
Click to collapse
That's true. The issue is they have used GB and GiB inconsistently.
Also, what is reported under 'System' is just a balancing figure, i.e. total storage minus sum of all other classifications.
The storage used by 'System' does vary for different storage variants of the same device model, but that difference is due to unit conversion. And where the system file manager isn't able to classify a particular file properly, it tends to include them under 'System', which causes more variation. I wonder why they even have a dedicated classification called 'Other files'.
Ideally, they should have a breakdown for 'System' to show the storage occupied by the OS (which should be identical for all storage variants of the same device model), and space occupied by System Files/ Data.
Anything else should go under 'Other files' and the Storage Analyser should list these files by size/ location. There is plenty of scope for improvement in how this tool displays information.

TheMystic said:
And where the system file manager isn't able to classify a particular file properly, it tends to include them under 'System', which causes more variation
Click to expand...
Click to collapse
No, there are fixed rules for classification that are stated in the AOSP.
TheMystic said:
Ideally, they should have a breakdown for 'System' to show the storage occupied by the OS
Click to expand...
Click to collapse
See attached file, infos are taken from the firmware.

TheMystic said:
The storage used by 'System' does vary for different storage variants of the same device model, but that difference is due to unit conversion.
Click to expand...
Click to collapse
There is no marketing issue or sth similar and there is no conversion issue. If you have 40GB in System then there is 40GB occupied by OS and system related files. No matter if GB or GiB. Occupied is occupied.
Edit: The attached pit file is valid for every model

WoKoschekk said:
No, there are fixed rules for classification that are stated in the AOSP.
Click to expand...
Click to collapse
Then Samsung doesn't seem to be following it properly.
WoKoschekk said:
See attached file, infos are taken from the firmware.
Click to expand...
Click to collapse
So the OS itself is 13.63 GB?
WoKoschekk said:
There is no marketing issue or sth similar and there is no conversion issue. If you have 40GB in System then there is 40GB occupied by OS and system related files. No matter if GB or GiB. Occupied is occupied.
Click to expand...
Click to collapse
Check this out:
[SOLVED] Difference in System Storage in March update
The allocation of storage between System and 'Other files' has changed after the Mar'23 update. Before the update, System was occupying 50.40 GB data. It was always this number for almost a year now (since the phone launched). But after the...
forum.xda-developers.com

TheMystic said:
Check this out:
Click to expand...
Click to collapse
I checked this out. But where do I find the proof for loss of storage due to conversion? Where is the proof for different occupied storage by system on all the different variants? All I can see is a single statement refering to this thread:
TheMystic said:
Also, the value of System will be different for devices with different storage sizes, even if it they are identical in all other aspects and are running on the same build of the OS.
Click to expand...
Click to collapse

TheMystic said:
So the OS itself is 13.63 GB?
Click to expand...
Click to collapse
Yes

WoKoschekk said:
where do I find the proof for loss of storage due to conversion?
Click to expand...
Click to collapse
There is no loss as such, but just that the space occupied by 'System' as shown by the built-in tool is a lot more than the actual space used by the OS and System Files.
WoKoschekk said:
Where is the proof for different occupied storage by system on all the different variants?
Click to expand...
Click to collapse
I don't have proof to show you now. You may find it on the internet. But it is a fact. The space occupied by 'System' as shown by the built-in tool is indeed significantly different for different storage variants of the exact same device. The reasons have been mentioned in the OP and the comments section.

TheMystic said:
There is no loss as such, but just that the space occupied by 'System' as shown by the built-in tool is a lot more than the actual space used by the OS and System Files.
Click to expand...
Click to collapse
How do you know that?
TheMystic said:
But it is a fact.
Click to expand...
Click to collapse
Because you can find it online...? Mmh... A detailed listing of those files would be helpful. But only a comparison of devices that are running since weeks/months says nothing.

WoKoschekk said:
How do you know that?
Click to expand...
Click to collapse
I have the details for my device (see attachments). As you would see, space occupied by 'System' has remained constant at 50.4 GB over the last 1 year of several updates. As you said, the OS is only about 14 GB. Which means the rest is basically difference in units used.
I have confirmed the different values reported between different storage variants of the exact same device. I don't have screenshots to show you now, but this is indeed true. The explanation for the difference is provided in comment #5.
WoKoschekk said:
A detailed listing of those files would be helpful.
Click to expand...
Click to collapse
The built-in tool doesn't provide a breakup for this value. But as mentioned in comment #5, the excess is mostly due to conversion of units.

WoKoschekk said:
If you have 40GB in System then there is 40GB occupied by OS and system related files. No matter if GB or GiB. Occupied is occupied.
Click to expand...
Click to collapse
Nope. That's why I wrote I had to read it twice