I like CM7 and would like to use it but the number of apps I have is probably greater than most of you guys......the /datadata folder only has like 150mb of app data storage and once I install like 100 apps it gets full and starts forceclosing....I know the Vibrant has 2gb of app storage but only in TouchWiz ROMs you can use the 2GBs not in AOSP....
Is there anyway to extend it? or atleast move the app folders somewhere to whe I can install all my apps and still have like 1GB left over...like I do in TW ROMs?
This isn't a Q and A ..it's sorta a discussion.
I've been doing a bunch of searching on this and it seems like all Galaxy S's on CM are having this problem. I'm assuming the fix is just as simple as editing a file somewhere but even that is too hard for me. Any help on this issue would be much appreciated.
Sent from my SGH-T959 using XDA App
It's the only thing keeping me from switching to it
data2sd script...
t1h5ta3 said:
data2sd script...
Click to expand...
Click to collapse
Well has anyone ever implemented it on CM for Galaxy S? From what I was reading this might fix a bunch of problems, but I have no idea how to actually use it to suit our needs.
Sent from my SGH-T959 using XDA App
Yea data2sd is necessary!
I can't seem to know how to apply this.....
Isn't there an option under "applications", that lets you install the apps on SD??
you can manually move apps to the sd or set it to just have it always download to the sd, I dont even have an external sd card and have 5 gb of space left
No that's not it......the APP partition is enough....the app data folder isnt and it is the problem..
basically in cm7, the 2gbs arent even used nor will ever
vinnydakid said:
I've been doing a bunch of searching on this and it seems like all Galaxy S's on CM are having this problem. I'm assuming the fix is just as simple as editing a file somewhere but even that is too hard for me. Any help on this issue would be much appreciated.
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
Without actually checking out the source code for cyanogenmod + android, I wouldn't exactly know. It is most likely a issue of partitioning. This would be changed at the source code level, not at the user end.
Because this thread has been stale, I've been digging into the reasoning of why samsung based phones have so ittle space in /data/data (i.e. /datadata). The most obvious way to compare this is through the command df -h.
Here is the output of df -h for the samsung vibrant (on CM7 nightly):
Code:
# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 165.0M 32.0K 165.0M 0% /dev
tmpfs 165.0M 0 165.0M 0% /mnt/asec
tmpfs 165.0M 0 165.0M 0% /mnt/obb
/dev/block/mtdblock2 187.5M 142.3M 45.2M 76% /system
/dev/block/mtdblock3 80.0M 36.3M 43.7M 45% /cache
/dev/block/mtdblock5 16.0M 14.3M 1.7M 89% /radio
/dev/block/mmcblk0p2 1.8G 591.4M 1.3G 31% /data
/dev/block/mtdblock6 172.0M 121.5M 50.5M 71% /datadata
/dev/block/mtdblock4 12.5M 6.6M 5.9M 53% /efs
/dev/block/vold/179:1
13.0G 4.2G 8.8G 32% /mnt/sdcard
/dev/block/vold/179:1
13.0G 4.2G 8.8G 32% /mnt/secure/asec
/dev/block/vold/179:9
3.7G 1.8G 1.9G 49% /mnt/emmc
Here is df -h for the HTC g2 (vision; CM7 Nightly):
Code:
# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 184.0M 32.0K 183.9M 0% /dev
tmpfs 184.0M 0 184.0M 0% /mnt/asec
tmpfs 184.0M 0 184.0M 0% /mnt/obb
/dev/block/mmcblk0p25
409.2M 147.4M 261.9M 36% /system
/dev/block/mmcblk0p26
1.3G 217.7M 1.0G 18% /data
/dev/block/mmcblk0p27
198.3M 39.5M 148.5M 21% /cache
/dev/block/mmcblk0p28
19.9M 14.7M 5.2M 74% /devlog
/dev/block/vold/179:65
14.9G 2.3G 12.6G 15% /mnt/sdcard
/dev/block/vold/179:65
14.9G 2.3G 12.6G 15% /mnt/secure/asec
Notice the difference? Apparently on samsung branded phones, the /data/data folder is on its *own partition*, formatted YAFFS2. On HTC based phones, the /data/data folder is not on its own partition, but apart of the /data mount. For some reason, the developers decided to put it in its own partition, vs. the standard convention.
Also, here is a comparision of mount points for the Vision (init.vision.rc) and Aries-common (shared device config; is the same in the init.vibrantmtd.rc):
Vision:
Code:
mkdir /system
mkdir /data 0771 system system
mkdir /cache 0770 system cache
mkdir /devlog 0700 root root
mount ext4 /dev/block/mmcblk0p25 /system wait ro barrier=1
mount ext4 /dev/block/mmcblk0p26 /data wait noatime nosuid nodev barrier=1 noauto_da_alloc
mount ext4 /dev/block/mmcblk0p27 /cache wait noatime nosuid nodev barrier=1
mount ext4 /dev/block/mmcblk0p28 /devlog wait noatime nosuid nodev barrier=1
Vibrantmtd:
Code:
mkdir /radio 0775 radio radio
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /cache
mount yaffs2 [email protected] /radio
mount ext4 /dev/block/mmcblk0p2 /data wait nosuid nodev noatime nodiratime noauto_da_alloc
mount yaffs2 [email protected] /datadata
Honestly, what I'm wondering, is why is /data/data not apart of the /data partition?
compuguy1088 said:
Because this thread has been stale, I've been digging into the reasoning of why samsung based phones have so ittle space in /data/data (i.e. /datadata). The most obvious way to compare this is through the command df -h.
Here is the output of df -h for the samsung vibrant (on CM7 nightly):
Code:
# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 165.0M 32.0K 165.0M 0% /dev
tmpfs 165.0M 0 165.0M 0% /mnt/asec
tmpfs 165.0M 0 165.0M 0% /mnt/obb
/dev/block/mtdblock2 187.5M 142.3M 45.2M 76% /system
/dev/block/mtdblock3 80.0M 36.3M 43.7M 45% /cache
/dev/block/mtdblock5 16.0M 14.3M 1.7M 89% /radio
/dev/block/mmcblk0p2 1.8G 591.4M 1.3G 31% /data
/dev/block/mtdblock6 172.0M 121.5M 50.5M 71% /datadata
/dev/block/mtdblock4 12.5M 6.6M 5.9M 53% /efs
/dev/block/vold/179:1
13.0G 4.2G 8.8G 32% /mnt/sdcard
/dev/block/vold/179:1
13.0G 4.2G 8.8G 32% /mnt/secure/asec
/dev/block/vold/179:9
3.7G 1.8G 1.9G 49% /mnt/emmc
Here is df -h for the HTC g2 (vision; CM7 Nightly):
Code:
# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 184.0M 32.0K 183.9M 0% /dev
tmpfs 184.0M 0 184.0M 0% /mnt/asec
tmpfs 184.0M 0 184.0M 0% /mnt/obb
/dev/block/mmcblk0p25
409.2M 147.4M 261.9M 36% /system
/dev/block/mmcblk0p26
1.3G 217.7M 1.0G 18% /data
/dev/block/mmcblk0p27
198.3M 39.5M 148.5M 21% /cache
/dev/block/mmcblk0p28
19.9M 14.7M 5.2M 74% /devlog
/dev/block/vold/179:65
14.9G 2.3G 12.6G 15% /mnt/sdcard
/dev/block/vold/179:65
14.9G 2.3G 12.6G 15% /mnt/secure/asec
Notice the difference? Apparently on samsung branded phones, the /data/data folder is on its *own partition*, formatted YAFFS2. On HTC based phones, the /data/data folder is not on its own partition, but apart of the /data mount. For some reason, the developers decided to put it in its own partition, vs. the standard convention.
Also, here is a comparision of mount points for the Vision (init.vision.rc) and Aries-common (shared device config; is the same in the init.vibrantmtd.rc):
Vision:
Code:
mkdir /system
mkdir /data 0771 system system
mkdir /cache 0770 system cache
mkdir /devlog 0700 root root
mount ext4 /dev/block/mmcblk0p25 /system wait ro barrier=1
mount ext4 /dev/block/mmcblk0p26 /data wait noatime nosuid nodev barrier=1 noauto_da_alloc
mount ext4 /dev/block/mmcblk0p27 /cache wait noatime nosuid nodev barrier=1
mount ext4 /dev/block/mmcblk0p28 /devlog wait noatime nosuid nodev barrier=1
Vibrantmtd:
Code:
mkdir /radio 0775 radio radio
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /cache
mount yaffs2 [email protected] /radio
mount ext4 /dev/block/mmcblk0p2 /data wait nosuid nodev noatime nodiratime noauto_da_alloc
mount yaffs2 [email protected] /datadata
Honestly, what I'm wondering, is why is /data/data not apart of the /data partition?
Click to expand...
Click to collapse
because leaving it on the moviNAND chip (even on ext4) is ****ing slow as balls. If you want, you can go back to stock Samsung ROM's where it's inside the /data partition and watch your phone crawl to a halt after a few days, even with voodoo lagfix (or any number of file systems). The choice becomes, do you want something fast and a good user experience and hope users actually think about what they're installing instead of being brain-dead "install ALL THE APPS" people... or have a miserable user experience for everyone to protect the few people who feel the need to install 150 apps on a phone (and then claim all are necessary)
Kaik541 said:
because leaving it on the moviNAND chip (even on ext4) is ****ing slow as balls. If you want, you can go back to stock Samsung ROM's where it's inside the /data partition and watch your phone crawl to a halt after a few days, even with voodoo lagfix (or any number of file systems). The choice becomes, do you want something fast and a good user experience and hope users actually think about what they're installing instead of being brain-dead "install ALL THE APPS" people... or have a miserable user experience for everyone to protect the few people who feel the need to install 150 apps on a phone (and then claim all are necessary)
Click to expand...
Click to collapse
That clarifies that reasoning. If there is that limitation, something needs to be implemented in code preventing applications from going outside of the max /datadata space (i.e. automated cleaning of app caches). Having the phone repeatedly crash over and over because of a lack of space in /datadata, isn't the best way to handle the situation.
Edit:
Doing df -h | grep -i datadata, works for many people (like me), but not everyone is command line savvy.
Edit2: I do not have 150 apps installed...but there are applications that store a decent ammount of data in the /datadata partition (youtube, facebook). This results in a juggling act just to have ~50 applications on the phone at one time. In my opinion, if you think that it should not be on the moviNAND, then the data partition should be mounted as well to the [email protected] partition. Like any other android device, this would work properly, and would prevent the severe strings of app crashes from the lack of space in /data/data.
compuguy1088 said:
That clarifies that reasoning. If there is that limitation, something needs to be implemented in code preventing applications from going outside of the max /datadata space (i.e. automated cleaning of app caches). Having the phone repeatedly crash over and over because of a lack of space in /datadata, isn't the best way to handle the situation.
Edit:
Doing df -h | grep -i datadata, works for many people (like me), but not everyone is command line savvy.
Edit2: I do not have 150 apps installed...but there are applications that store a decent ammount of data in the /datadata partition (youtube, facebook). This results in a juggling act just to have ~50 applications on the phone at one time. In my opinion, if you think that it should not be on the moviNAND, then the data partition should be mounted as well to the [email protected] partition. Like any other android device, this would work properly, and would prevent the severe strings of app crashes from the lack of space in /data/data.
Click to expand...
Click to collapse
except the slowest part of loading an application is what's pulled from /data/data, not from /data/app (or app-private). On top of that, it would limit our /data partition to ~170 MB for both /data/app(-private) and /data/data, which would mean like 15 apps total for everyone... again, creating a miserable user experience for all. Then what? we relegate mmcblk0p1 to...? /sdcard? /emmc? /wastedinternalstorage? it can't simply be "merged" into the other things. if you don't know how to manage your apps/space, then that's on you. every partition will have this same failing, android has no way of verifying "out of space" besides the /cache and /data partitions (and even then, it only goes "oops out of space" when it already fails). Putting /data/data on a faster partition (that other phones don't HAVE to make this decision like we did) over putting it inside /data is monumentally different on our phone. we're the only device in CyanogenMod history that went from one partition layout format (BML) to another (MTD). Sure, others have resized their MTD partitions (HardSPL on Dream/Sapphire fore example), but they were already on MTD. Ours required re-working the way the phone even *exists*, on top of that, there are partitions and spaces we are literally incapable of editing or modifying.
basically, while it's easy to say "meh, I don't like this way because it makes my life harder", for 95% of users, it's the far more optimal choice and leads to a far superior user experience. if you are technical enough to install CM, you should be technical enough to know how to run a simple command from terminal emulator (which is included in CM by default).
Kaik541 said:
except the slowest part of loading an application is what's pulled from /data/data, not from /data/app (or app-private). On top of that, it would limit our /data partition to ~170 MB for both /data/app(-private) and /data/data, which would mean like 15 apps total for everyone... again, creating a miserable user experience for all. Then what? we relegate mmcblk0p1 to...? /sdcard? /emmc? /wastedinternalstorage? it can't simply be "merged" into the other things. if you don't know how to manage your apps/space, then that's on you. every partition will have this same failing, android has no way of verifying "out of space" besides the /cache and /data partitions (and even then, it only goes "oops out of space" when it already fails). Putting /data/data on a faster partition (that other phones don't HAVE to make this decision like we did) over putting it inside /data is monumentally different on our phone. we're the only device in CyanogenMod history that went from one partition layout format (BML) to another (MTD). Sure, others have resized their MTD partitions (HardSPL on Dream/Sapphire fore example), but they were already on MTD. Ours required re-working the way the phone even *exists*, on top of that, there are partitions and spaces we are literally incapable of editing or modifying.
basically, while it's easy to say "meh, I don't like this way because it makes my life harder", for 95% of users, it's the far more optimal choice and leads to a far superior user experience. if you are technical enough to install CM, you should be technical enough to know how to run a simple command from terminal emulator (which is included in CM by default).
Click to expand...
Click to collapse
It was a crazy shot in the dark. I was actually thinking of the possiblity of having a service clear the caches of all programs on boot. I *have* been managing my space that way. For some apps (*cough* facebook), they decide to use 20+ megabytes of space that is not cache. I understand your justification, but If this is the way things are going to be for Aries based phones (Galaxy S, Fascinate, Vibrant, etc), this should be mentioned in the OT. People should know before flashing this rom, that manual management is a necessary.
Ive been on simply honey for about 2 weeks and have shortened to 273 apps and it is still fast....I don't notice lag....maybe I'm crazy I don't notice the difference between full of apps and newly flashed simply honey.....am I crazy?
Sent from my SGH-T959 using XDA Premium App
Alanrocks15 said:
Ive been on simply honey for about 2 weeks and have shortened to 273 apps and it is still fast....I don't notice lag....maybe I'm crazy I don't notice the difference between full of apps and newly flashed simply honey.....am I crazy?
Sent from my SGH-T959 using XDA Premium App
Click to expand...
Click to collapse
Unless Simply Honey is based on Cyanogen 7, this issue does not apply to you. What is being discussed is the nightlies for the upcoming CM 7.1 relating to a partitioning decision. Based on what I've read and seen in the source code, is a dirty hack. It allows for faster performance, at the cost of the need to micro manage applications use of a limited /datadata. If this is going to reach an actual stable realase, this needs to be reverted. The mass majority of people do not have the time, nor the desire to every so often manually clean out data and caches of "/datadata" hogs. Most people who are still using the galaxy s line of phones have gotten use to the slow read and write speeds of the moviNAND by now....
Kaik541 said:
basically, while it's easy to say "meh, I don't like this way because it makes my life harder", for 95% of users, it's the far more optimal choice and leads to a far superior user experience. if you are technical enough to install CM, you should be technical enough to know how to run a simple command from terminal emulator (which is included in CM by default).
Click to expand...
Click to collapse
For many phones, including the galaxy S line, it is *very* easy to install CM (no command line use needed). I understand your (and the CM maintainers) decision to do this. I also see the reasons *not to*, in the eyes of average users. I think the performance penalties for more space in /datadata, are worth more than the need to have users digging around the phone system every other week. This is my opinion, based on my educational background and experience.
nah I read how the other Guy said how it is slow even with lagfix if you get a bunch of apps .....
Sent from my SGH-T959 using XDA Premium App
Alanrocks15 said:
nah I read how the other Guy said how it is slow even with lagfix if you get a bunch of apps .....
Sent from my SGH-T959 using XDA Premium App
Click to expand...
Click to collapse
That is true on any normal vibrant rom. For cm7.1 based roms, they basically moved the most heavily read and written directory to high speed flash. The cm developers solved one problem (slowness), and created a completely new issue (lack of space in /datadata). This is what he was trying to say, in a nutshell.
Sent from my SGH-T959 using Tapatalk
Okay i didn't really understand the part where you put all those values and things so what will happen? Is this problem going to remain?
Related
In short: When I install a new app, the app gets installed in /system/sd just fine (/data/app and /data/app-private symlinks work just fine) , but /data increases a little too.
before installing seesmic and pandora df shows:
Code:
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 197584 0 197584 0% /dev
tmpfs 4096 0 4096 0% /sqlite_stmt_journals
/dev/block/mtdblock3 148480 110484 37996 74% /system
/dev/block/mtdblock5 200960 [B][COLOR="Blue"]62260[/COLOR][/B] 138700 31% [B]/data[/B]
/dev/block/mtdblock4 97280 39952 57328 41% /cache
/dev/block/mmcblk0p2 702873 [B]97721 [/B]567652 15% [B]/system/sd[/B]
/dev/block/mmcblk0p2 702873 97721 567652 15% /data/dalvik-cache
/dev/block//vold/179:1
14898512 827680 14070832 6% /sdcard
After installing seesmic and pandora df shows:
Code:
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 197584 0 197584 0% /dev
tmpfs 4096 0 4096 0% /sqlite_stmt_journals
/dev/block/mtdblock3 148480 110484 37996 74% /system
/dev/block/mtdblock5 200960 [B][COLOR="Red"]62544 [/COLOR][/B] 138416 31% [B]/data[/B]
/dev/block/mtdblock4 97280 41280 56000 42% /cache
/dev/block/mmcblk0p2 702873 [B]100347 [/B]565026 15%[B] /system/sd[/B]
/dev/block/mmcblk0p2 702873 100347 565026 15% /data/dalvik-cache
/dev/block//vold/179:1
14898512 827680 14070832 6% /sdcard
Notice that /data increased by 300KB. Anyone know why?
why is my /data partition 31% used?
Yes, the size of the /data partition does increase even with apps2sd enabled... and from a quick analysis of the /data partition (with apps2sd enabled), I noticed this...
1. the applications are installed on the sd card and the /app & /app-private are symlinked
2. the application information is stored in /data/system/packages.xml (kinda like the windows registry)
3. some application data like shared prefs, extra libs (if any) are stored in /data/data
i guess this accounts for the usage size increase!!!
It looks like the apps are getting is installed to the sd card fine, but the app data still gets stored in the internal ROM
/data/data has 157 folders and is 52MB
/system/sd/app-private has 0 files and is 1K
Therefore it looks like either the apps2sd implementation is incomplete, or didnt get installed correctly.
Anyone tried moving /data/data to /system/sd/app-data and creating a symlink for it? (trying this now...)
darn it. after a reboot the OS removed my symlink, created a new /data/data folder, and apps are still writing to this folder now. lucky i made a backup.
... maybe while booting it saw that the /system/sd/app-data link was invalid (not mounted yet), and hence re-created the folder.
Been searching tons of forums for answer, seems like no ones problem is quite like mine though, so...Time to ask you guys
I'm running newest RA-Amon Recovery
I'm running Damage Control 2.09.01
I have been TRYING to get A2SD working correctly for a few days now with no luck....
I've formatted my card, wiped my phone, partitioned SD as follows:
Swap 32mb
Ext 2 512mb (Changed to Ext 3)
Fat32 Remainder
Not sure if it matters, but I have a 32GB SD card...
When I run busybox df -h this is what I get:
C:\AndroidSDK\tools>adb shell
# busybox df -h
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 95.5M 0 95.5M 0% /dev
tmpfs 4.0M 4.0K 4.0M 0% /sqlite_stmt_journals
/dev/block/mtdblock3 170.0M 141.6M 28.4M 83% /system
/dev/block/mtdblock5 159.5M 67.1M 92.4M 42% /data
/dev/block/mtdblock4 130.0M 1.1M 128.9M 1% /cache
/dev/block/mmcblk0p2 457.4M 5.0K 433.0M 0% /system/sd
/dev/block//vold/179:1
30.7G 31.5M 30.7G 0% /sdcard
Also, if I try to install a program from Market, it downloads fine, but Fails to Install due to Insufficient Storage
If anyone has any ideas or would like me to try something else, I'm all ears. Phone starting to frustrate me
Don't know if this will work, but try this:
Go into an adb shell. Type this:
cd /data/data/com.android.vending/cache
rm -f *
reboot
This will clear the market cache and reboot your phone.
Let me know if that works.
kronik03 said:
Been searching tons of forums for answer, seems like no ones problem is quite like mine though, so...Time to ask you guys
I'm running newest RA-Amon Recovery
I'm running Damage Control 2.09.01
I have been TRYING to get A2SD working correctly for a few days now with no luck....
I've formatted my card, wiped my phone, partitioned SD as follows:
Swap 32mb
Ext 2 512mb (Changed to Ext 3)
Fat32 Remainder
Not sure if it matters, but I have a 32GB SD card...
When I run busybox df -h this is what I get:
C:\AndroidSDK\tools>adb shell
# busybox df -h
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 95.5M 0 95.5M 0% /dev
tmpfs 4.0M 4.0K 4.0M 0% /sqlite_stmt_journals
/dev/block/mtdblock3 170.0M 141.6M 28.4M 83% /system
/dev/block/mtdblock5 159.5M 67.1M 92.4M 42% /data
/dev/block/mtdblock4 130.0M 1.1M 128.9M 1% /cache
/dev/block/mmcblk0p2 457.4M 5.0K 433.0M 0% /system/sd
/dev/block//vold/179:1
30.7G 31.5M 30.7G 0% /sdcard
Also, if I try to install a program from Market, it downloads fine, but Fails to Install due to Insufficient Storage
If anyone has any ideas or would like me to try something else, I'm all ears. Phone starting to frustrate me
Click to expand...
Click to collapse
i just flashed to JP3 followind the useful guide from this forum. it all went well, seems verry snappy, bu i have one problem... if i try to install fifa 10 it says i`m out of space "clean up some space and try again". also, if i try to install NOVA for example, it goes thru with the installation but when it starts it says "an SD card with at least 7mb is needed to download" even after i preveously copied the game cache to the SD card....
i forgot to mention some things :
1. i dont have a "lag fix"
2. the external SD, the internal Sd and the phone memory, all have at least 2 GB of free space!
I cannot find a fix anywhere on he internet even know i tried to ...
thank you in advance and excuse my english
hm. make a
busybox df -h
please ...
I am also having problem installing game w update. anyone know why we having this problem?
same here. What I heard is that the 2.2 rom mount phone memory to /internal_sd instead of /sdcard and it causes the problem....
evermick said:
same here. What I heard is that the 2.2 rom mount phone memory to /internal_sd instead of /sdcard and it causes the problem....
Click to expand...
Click to collapse
that may be the case but i also have about 2GB of unused disk space on the internal sd, so it should work ...
jodue said:
hm. make a
busybox df -h
please ...
Click to expand...
Click to collapse
i have the same problem. just installed busybox + rooted
$ su
su
# busybox df -h
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 152.4M 0 152.4M 0% /dev
df: /mnt/.lfs: Function not implemented
tmpfs 152.4M 0 152.4M 0% /mnt/asec
/dev/block/stl9 275.8M 271.8M 4.0M 99% /system
/dev/block/mmcblk0p2 1.9G 68.1M 1.8G 4% /data
/dev/block/stl10 127.2M 10.9M 116.3M 9% /dbdata
/dev/block/stl11 30.1M 32.0K 30.0M 0% /cache
/dev/block/stl3 5.9M 4.0M 1.9M 68% /efs
/dev/block/vold/179:1
5.8G 1012.9M 4.8G 17% /mnt/internal_sd
/dev/block/vold/179:9
7.6G 259.4M 7.3G 3% /mnt/internal_sd/externa
l_sd
/dev/block/vold/179:9
7.6G 259.4M 7.3G 3% /mnt/secure/asec
#
please help!
It is only the most reported bug in froyo.... Have you even tried to read the forum?
And no, there is no fix f for it.
Sent from my GT-I9000 using XDA App
I followed the instructions to install Nookie Froyo 0.6.8 CWR for eMMC from this thread. I installed on a restored to stock NC. After successfully installing Nookie Froyo, I removed the sdcard and formatted it on my PC. Unfortunately, somehow my partitions got all jacked up at some point in this process. Froyo recognizes my sdcard but when I transfer apps to the sdcard they get moved to /mnt/asec which for no apparent reason is only 244mb. I've run out of space even though I have a 4GB Class 6 sdcard. Would one of you take a look at my partitions below and tell me how to fix this?
Code:
# df -h
df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 244.2M 12.0K 244.2M 0% /dev
tmpfs 244.2M 0 244.2M 0% /mnt/asec
/dev/block/mmcblk0p2 69.5M 105.0K 69.4M 0% /rom
/dev/block/mmcblk0p5 440.5M 111.5M 324.5M 26% /system
/dev/block/mmcblk0p6 941.9M 135.5M 758.6M 15% /data
/dev/block/mmcblk0p8 5.0G 7.3M 5.0G 0% /media
/dev/block/mmcblk0p7 341.8M 10.2M 313.9M 3% /cache
/dev/block/vold/179:17
3.8G 635.0M 3.1G 17% /mnt/sdcard
/dev/block/vold/179:17
3.8G 635.0M 3.1G 17% /mnt/secure/asec
For the record, I moved all my apps back to "phone" just to be safe, so that's why /mnt/asec indicates 0 space used.
Any Nookie Froyo experts out there that can offer some insight?
Really, nobody?
Somebody that used brianf21's Nookie Froyo 0.6.8 CWR for emmc just take a look at your partitions and tell me what's different or post your vold files so I can see if mine is different or corrupted.
To see your partitions, open up terminal and type:
su
df -h
/mnt/asec is where App2SD apps are Mounted and Run from. I've run into the storage problem too and haven't been able to research it because I was traveling. If I find something I'll let you know.
____________________________________________________
Sent from Nookie Froyo using Tapatalk
Thanks. I could use whatever help I can get.
Sent from my DROID2
After unlocking the bootloader, flashing TWRP and getting rid of some firmware-baked apps, my phone's system partition has over 1Gigabyte of free space.
df -h returns:
Code:
Filesystem Size Used Available Use% Mounted o
tmpfs 430.5M 20.0K 430.4M 0% /dev
tmpfs 430.5M 248.0K 430.2M 0% /tmp
/dev/block/mmcblk0p41 246.1M 4.2M 241.9M 2% /cache
/dev/block/mmcblk0p42 4.8G 3.5G 1.3G 74% /data
/dev/block/mmcblk0p42 4.8G 3.5G 1.3G 74% /sdcard
/dev/block/mmcblk0p1 62.4M 57.9M 4.5M 93% /firmware
/dev/block/mmcblk0p40 1.9G 855.4M 1.1G 43% /system
/dev/block/mmcblk1p1 29.0G 14.1G 14.8G 49% /sdcard1
(note: it's for the XT1072 running MM)
How would I go about resizing mmcblk0p40 to 1G so the freed 900M can be assigned to mmcblk0p42? I'm guessing I need to tool around with the partition tables using parted and then format? Can I accomplish it without touching all the other partitions?
I've looked around and the general wisdom seems to be "do not mess with internal partitions". It should be doable, though? I'm generally aware of the risks involved. I've made a NANDroid backup and I plan to tread very carefully around the boot and other dozens of key partitions.
Any guide or account of the tools needed would be much appreciated!
S_droid said:
How would I go about resizing mmcblk0p40 to 1G so the freed 900M can be assigned to mmcblk0p42?
Click to expand...
Click to collapse
this is being done on many devices. see REPIT:
https://github.com/Lanchon/REPIT
but...
check these issues:
https://github.com/Lanchon/REPIT/issues/55
https://github.com/Lanchon/REPIT/issues/56