Related
So as we all know /cache is used for OTA updates which, when you have your phone rooted is useless.
What I'm wondering is why we can't use /dev/block/mtdblock4 (aka /cache) as a permanent onboard swap partition. Granted it will only give us an additional 30MB but the speed of this swap will be higher than that of our sdcard.
In order to test this we'll have to:
convert this partition to a linux-swap partition.
mkswap /dev/block/mtdblock4
update init.rc to no longer mount this as yaffs2
add this new swap space to the swap script
The issue is of course being able to run a partition utility on the phone. Second, if this doesn't work we don't have a way to format /cache back to yaffs2 (that I know of).
If you have experience with any of the issues I listed above please comment/post. If you don't have a clue please don't post so we can keep this thread clean. I would appreciate only experienced devs responding.
If this is possible it would benefit Hero/MotoBlur ROMS which are memory intensive.
For your second concern, why would we need to change it back to /cache? Just make it a disclaimer when people attempt this operation.
More importantly, I think the primary issue is that this is rom space is it not? Doesn't this portion of the memory have a limited amount of times that it could be written to?
Hmm why not trying "parted /dev/block/mtdblock4" in recovery? ;-)
rest would be easy.
Couldn't we use mkyaffs2img (in recovery /sbin) to turn it back into yaffs?
persiansown said:
For your second concern, why would we need to change it back to /cache? Just make it a disclaimer when people attempt this operation.
More importantly, I think the primary issue is that this is rom space is it not? Doesn't this portion of the memory have a limited amount of times that it could be written to?
Click to expand...
Click to collapse
Well my concern was if there was some adverse effect of removing /cache from the system we'd need a way to revert back.
I am not aware of any MAX amount of times that /cache can be written to.
*Edited*
Due to unintelligent comments and moronism prevalent in this thread, I removed a line from this post to keep us on track of what this thread was meant to discuss.
There's another thing:
Recovery can't be used without /cache !
So we need to convert back each shutdown and convert to linux-swap each startup..
dumfuq said:
Couldn't we use mkyaffs2img (in recovery /sbin) to turn it back into yaffs?
Click to expand...
Click to collapse
I hadn't checked in the recovery img for any yaffs2 utilities. But if that indeed does exist then this will be possible.
So then the issue would be, is this safe to attempt long term with the amount of writes being done to internal flash?
maxisma said:
There's another thing:
Recovery can't be used without /cache !
So we need to convert back each shutdown and convert to linux-swap each startup..
Click to expand...
Click to collapse
So I see recovery is using it but the only thing in it is the recovery logfile. Could we modify the recovery to read/write the logfile to system/sd/recovery or something, or is the cache used for other stuff as well?
Another idea:
Instead of using it as swap, what if we could find a way to use it as compcache space? That way we don't sacrifice any of the internal ram for compcache and still have compcache running
maxisma said:
There's another thing:
Recovery can't be used without /cache !
So we need to convert back each shutdown and convert to linux-swap each startup..
Click to expand...
Click to collapse
What part of recovery needs /cache ? Does the recovery img mount the /cache partition? I'm wondering if the recovery img could be modified to write to the ext2 partition such as /system/sd/cache .
persiansown said:
Another idea:
Instead of using it as swap, what if we could find a way to use it as compcache space? That way we don't sacrifice any of the internal ram for compcache and still have compcache running
Click to expand...
Click to collapse
This is actually a good idea and it'd be interesting to see which way would benefit us more.
shafty023 said:
What part of recovery needs /cache ? Does the recovery img mount the /cache partition? I'm wondering if the recovery img could be modified to write to the ext2 partition such as /system/sd/cache .
Click to expand...
Click to collapse
When you activate an option in recovery, for example install update.zip, it writes the command into /cache/recovery and does a "quick reboot", which reads out the command and does this.
ok first dont even try it would one
reduce life on nand
cause issues with flashing
slow down any thing accessing the nand.
to the person thinking the ram is using flash. you must have never been to high school cause even typing class explains what ram is. plus g1 has memory write speeds of about 120mb/sec thats sdram. swap will never replace ram 120mb/sec versus 6 is huge
if you want real improvements you must change the code to something more efficient.
less bloat
more native code
fewer clock cycles
improved app states(cache on sd that would save the state by dumping part of ram to load later reducing clock cycles and reducing ram)
and my favorite rewrite system libs and apps to include more native code and reducing ram usage.
btw native code is about 10-100x faster than android java. that means 10%-100% more speed(or less load)
you could make a swap file and put it on there and just mount the file...........
yeah what he said!
zenulator said:
you could make a swap file and put it on there and just mount the file...........
Click to expand...
Click to collapse
This sounds like a good idea, altho we would have to get compcache working with backing swap file.
do we know if the /cache speed is compaired to Class 6 microSD?
good luck hardheads
jokersax11 said:
ok first dont even try it would one
reduce life on nand
cause issues with flashing
slow down any thing accessing the nand.
to the person thinking the ram is using flash. you must have never been to high school cause even typing class explains what ram is. plus g1 has memory write speeds of about 120mb/sec thats sdram. swap will never replace ram 120mb/sec versus 6 is huge
Click to expand...
Click to collapse
Dude honestly get a life. I have a Bachelor's degree in Computer Science. And I could code in Intel Assembly accessing each and every register in memory while you're left googling what Intel Assembly code means. Maybe you should keep up with the latest technology. If you did you'd know there are all-in-one memory chips that support NOR, NAND flash, and RAM.
http://www.eetasia.com/ART_8800466798_499486_NT_ab9e537f.HTM
jokersax11 said:
if you want real improvements you must change the code to something more efficient.
less bloat
more native code
fewer clock cycles
improved app states(cache on sd that would save the state by dumping part of ram to load later reducing clock cycles and reducing ram)
and my favorite rewrite system libs and apps to include more native code and reducing ram usage.
btw native code is about 10-100x faster than android java. that means 10%-100% more speed(or less load)
Click to expand...
Click to collapse
Exactly what type of "native code" are you referring to? And do you have any idea what type of memory the G1 uses for RAM? Go back to your typing class.
Shafty did you see Zenulator's idea? That seems like it could work.. Does the phone ever format the cache partition?
I posted this in a thread in the Dev. section but that's probably not the appropriate place for it - I've been installing ROMS (SCV7, Swifty Trix) with BootMenu on the second system with Leak #1 on the primary system. On the primary system I have ~ 4 gigs allotted to app storage and on the second I only have ~ 200 mbs. I can't even begin to install a basic set of application... are there any suggestions on how to remedy this situation? I've been Google-ing the subject but haven't found much information so far.
EDIT - So, I guess "RTFM" should always be in mind:
Q: I have a "low storage space" on 2nd system?
Webtop partition size is only 1.3GB.
To make thing simple, the included boot_second.sh script bind mount /system & /data inside this webtop partition.
You have at least 4 option, if you want to have bigger /data
1.Reassign /data to /sdcard (IO speed depend on sdcard speed rating)
2.Reassign /data to /dev/block/userdata (this will replace all your data for stock system)
3.Reassign /data to /dev/block/cache (bind /cache to somewhere else e.g : /webtop/cache)
4.Use a lightweight ROM (/system size = small)
You need to modify these files to suit your needs.
/preinstall/bootmenu/script/boot_stock.sh
/preinstall/bootmenu/config/stock.recovery.fstab
/preinstall/bootmenu/script/boot_second.sh
/preinstall/bootmenu/config/second.recovery.fstab
Sorry, for now you all have to configure this files manually.
--------
So, this is a little beyond what I've done with Android thus far... for now I haven't been able to figure out how to work it out. Any suggestions would be much appreciated. Thanks!
goto
1) mounts/format
2) format webtop
3) toggle second system recovery (main menu)
4) install/restore whichever ROM u desire
i think erasing webtop will pretty much free system space in "second system"
and remember second system is usually considered as trial purpose
as far as my exp. changing something in first system will somtime affect the second system
Happy flashing
aguacateojos said:
I posted this in a thread in the Dev. section but that's probably not the appropriate place for it - I've been installing ROMS (SCV7, Swifty Trix) with BootMenu on the second system with Leak #1 on the primary system. On the primary system I have ~ 4 gigs allotted to app storage and on the second I only have ~ 200 mbs. I can't even begin to install a basic set of application... are there any suggestions on how to remedy this situation? I've been Google-ing the subject but haven't found much information so far.
EDIT - So, I guess "RTFM" should always be in mind:
Q: I have a "low storage space" on 2nd system?
Webtop partition size is only 1.3GB.
To make thing simple, the included boot_second.sh script bind mount /system & /data inside this webtop partition.
You have at least 4 option, if you want to have bigger /data
1.Reassign /data to /sdcard (IO speed depend on sdcard speed rating)
2.Reassign /data to /dev/block/userdata (this will replace all your data for stock system)
3.Reassign /data to /dev/block/cache (bind /cache to somewhere else e.g : /webtop/cache)
4.Use a lightweight ROM (/system size = small)
You need to modify these files to suit your needs.
/preinstall/bootmenu/script/boot_stock.sh
/preinstall/bootmenu/config/stock.recovery.fstab
/preinstall/bootmenu/script/boot_second.sh
/preinstall/bootmenu/config/second.recovery.fstab
Sorry, for now you all have to configure this files manually.
--------
So, this is a little beyond what I've done with Android thus far... for now I haven't been able to figure out how to work it out. Any suggestions would be much appreciated. Thanks!
Click to expand...
Click to collapse
All of that is not needed, and you will mess up your install on first system too.
I get trying new things out and trail blazing, but next time do a little research first. There are people who don't think and search for a problem and find your solution try it and learn they now have to fxz, but don't know how or can't.
This appears to be way beyond you. Next time try something a little smaller and less likely to screw something up for those that don't know or not very capable.
shardul.phatak said:
goto
1) mounts/format
2) format webtop
3) toggle second system recovery (main menu)
4) install/restore whichever ROM u desire
i think erasing webtop will pretty much free system space in "second system"
and remember second system is usually considered as trial purpose
as far as my exp. changing something in first system will somtime affect the second system
Happy flashing
Click to expand...
Click to collapse
What he said ^^
The Hefe Hook kernel allows you to mount a partition of your microSD as /data, getting 2 GB (or more) for your apps and their data.
Please ask your questions here about installation, use, or general approach.
This is great @jeffsf and can u show me how to re-partition the "real internal" storage? I mean expanding the /system since u put the /data out of it. Thanks man
Sent from my GT-N7000 using Tapatalk 2
daothanhduy1996 said:
This is great @jeffsf can u show me how to re-partition the "real internal" storage? I mean expanding the /system since u put the /data out of it.
Click to expand...
Click to collapse
Yes, you've hit on another of the reasons I've been exploring using the microSD for "live" storage. It's one thing to use potentially slow storage for photos that you basically write once or "app to SD" where you read the APK at boot time, make sure your ODEX in the Davlik cache is good, then generally read from the internal-flash cache. It is another when that memory is being read and written "constantly" when your phone is running.
The good thing is that once /data is not part of the internal flash filesystem, you don't have to worry about one ROM (kernel) thinking it begins at one place and another saying it starts at another. Previously, if one ROM had one /system size and another and a different one, the next partition, /data, would look to be corrupt when you swapped ROMs.
As a warning, not all users have fast microSD cards. Some that say "Class 10" on them really are dogs, especially for small reads/writes. The "Class" ratings are for sustained writes, as you would have with a camera recording video. If your ROM is "external /data" only, or even defaults to that, be prepared for a slew of "Your ROMs sucks. It is so slow." complaints.
You'll also need a way to automate formatting the card. It can be done on the phone, as long as you aren't trying to preserve any data.
As I recall, the layout of the MTD partitions is done in drivers/mtd/onenand/samsung_galaxys4g.h I would be careful not to move the partition boundary for efs, as you'd have to move the data it contains in your updater script. Repeating the warning about not moving the boot and recovery partitions is probably a good idea as well!
Your build tree may need some of these values, or at least think it needs some of these values. For example, device/samsung/aries-common from the CyanogenMod/cm-11.0 (KitKat) branch calls out NAND page sizes, partition sizes, and flash block sizes. I haven't looked in detail at your build tree so I can't comment on how it might handle things differently than the CyanogenMod one.
itzik2sh said:
Hi
I hope I don't ask anything silly, but please let me know if any of my assumptions is wrong :
1. I take FBi's251's AOKP milestone 6 (ICS 4.0.4)
2. 8GB SDCard was formatted to FAT32 (4GB) and EXT3 (4GB) using TWRP kernel
(Beastmode's proton kernel to be exact).
3. I would flash this kernel and it would move apps and their data to the sd-ext
without any special additions.
Thanks. I read the thread, but unfortunately 8GB SD is what i have and I think it should be enough.
Thanks again.
P.S - it's for 2 guys I already sold them my SGS4Gs. I want them to be happy...
Click to expand...
Click to collapse
AOKP should be fine. I haven't tried it recently, but it was the tree in which I did the early Hefe Kernel development.
As I understand it, you have a microSD with
partition 1: 4 GB FAT32
partition 2: 4 GB ext3
So that can work, but will need some tweaking of the init-on-fs.sh script. I intentionally didn't use the second partition as so many scripts gobble that up as sd-ext and do who knows what to it.
My first preference would be to reformat the cards, perhaps:
6 GB FAT32
1 MB ext2/3/4 (Yes, 1 MB, a sliver, choice of ext2, ext3, ext4 up to you)
2 GB ext4
since then the script will work without modification and if they install a third-party script that uses the second partition, it won't corrupt their data.
If you were to keep the formatting the way that it is now, you'd need to edit the mount commands in the script to look something like:
Code:
/system/xbin/busybox umount /data
/system/xbin/busybox mount -t ext3 -o noatime /dev/block/mmcblk0p2 /data
(removing the sd-ext mount)
I'm not sure what your expectations are, but all that the kernel and that script will do is mount a different disk partition on /data -- you need to manually move the data over (or restore from something like Titanium Backup). There may be some trickery in renaming that could be used with TWRP backups to restore from data.yaffs2.win to the new /data partition, but I haven't tried that at all.
Hi Jeff
Thanks for your quick reply, and sorry again for not seeing the Q&A thread.
I think making it :
partition 1: 4 GB FAT32 (sdcard)
partition 2: 2 GB ext3 (sd-ext)
partition 3: 2 GB ext3 (data)
partition 4: 1 MB (spare)
would be better and handle data as well. don't you think ?
Would it be worth doing with a "Team" micro-SD card (class 6 I believe) ?
Thanks.
I haven't tried a Class 6 card, but my gut feeling is that it will be dicey. I didn't "commit" to using /data on microSD until I had tried it for several days using Titanium Backup's ability to move both apps and app data to the external card. I would try that first, especially as the phones in question aren't going to be in your hands (I consider you an expert user, able to manage things outside the UI with ease).
I've attached some testing I did a while ago with Transcend and SanDisk cards. When you look at them, realize that the speed scale changes between them. I have a feeling that the real "performance" on a device is going to be related to relatively small reads and writes, not the ability to stream video to the card. I also don't know much about the Team brand, but I found that even some well-known brands didn't have the performance of the Transcend or SanDisk in the same category.
However you configure your cards, I would definitely recommend a journaling filesystem of some sort. I've had my microSD come loose inside the phone. The journal will at least help to reduce any filesystem corruption should that happen.
You don't need the fourth partition -- I have it there to be able to keep rsync backups for fast ROM swapping.
.
Regarding the apps data, have you tried exploring the Mount2SD script ?
sent from me
I've tried a couple of the scripts out there in the past. Since backing up my data is very important to me, I trust the scripts in Titanium Backup to work well with its backup/restore strategies.
Mounts2SD looks like it has gotten a lot more sophisticated than it was when I tried it in the past. It sounds like something worth trying in its current state. At a quick glance (and not looking at the code), I'd personally make some different choices about features; enabling journaling, and being concerned about why lost+found was filling up (things should only appear there if the file system is found to be corrupt).
Hello everyone, how can I resize my /system and /data partitions?
I've noticed that my system partition is 2.2GB big, but my system is using only 1G of it.
Meanwhile, my data partition, where the apps are stored, has 3.9 out of 4.5G in use.
Is it feasible to resize those?
If so, can you link me to any good how-to on how to do it? I would be very happy to have 0.7G more in my /Data partition.
Thanks in advance.
I've attached a pic of the issue.
frenchiveruti said:
Hello everyone, how can I resize my /system and /data partitions?
I've noticed that my system partition is 2.2GB big, but my system is using only 1G of it.
Meanwhile, my data partition, where the apps are stored, has 3.9 out of 4.5G in use.
Is it feasible to resize those?
If so, can you link me to any good how-to on how to do it? I would be very happy to have 0.7G more in my /Data partition.
Thanks in advance.
I've attached a pic of the issue.
Click to expand...
Click to collapse
Last time I messed with the partitions I semi-bricked my phone and had to restore stock firmware via ADB and fastboot. Won't be doing that again anytime soon. I am sure it can be done just be careful, goodluck.
Don't do it... really... this device has 20+ partitions, and messing with them almost always results in a non-bootable condition, and sometimes in hard brick state, and since we don't have the proper QDLoader files (and never will), it makes it a perma-brick. Messing with partitioning on newer device is problematic at best, because we can only access about 5-8 of the partitions out of the 20 or so on the device, but on the Moto without Qualcomm QDLoader recovery files, it is almost impossible.
Ok, good to know that I must not do it then.
Thanks for the replies!
This is just an idea. I tried it on my Nokia 6.1 (2018) (PL2) running Android 10, and it worked; so I thought it might work on other devices too. My device:
Android 10 Q
System-as-root
A/B slots
Released with Project Treble support (and hence has the fstab in the vendor partition)
DM-verity, force-encryption and disk quota disabled with this mod by Zackptg5.
It basically uses a single partition to store the contents of what I call two different userdata "profiles". Normally, you have one userdata partition on a device, and that stores one profile. Here, however, I used a subdirectory on the root of the userdata partition to store the contents of the second profile, and modified the fstab to correctly bind-mount it on /data. Bind-mounting made things simple in my opinion--I didn't have to go about actually repartitioning my storage. The reason this works is that any changes you make to your phone on the lines of installing and updating apps, downloading files, changing settings, etc. are all reflected only on the userdata partition. No other partition on an android phone is ever touched unless the system is updated. Hence, the userdata partition is the only partition you need to mess around with in order to have two profiles.
===================================​DISCLAIMER:
I am NOT sharing a solution. I am only sharing an idea for you to try and/or improvise on. It may work, it may not. I will not hold your hand; you will have to use your own knowledge and common sense. I am not responsible for anything that goes wrong on your device.
If you do not understand what is going on in this post, please do not try this.
There is a reason I'm not explaining all the terms I'm using here. I assume that if you, the reader, want to try this out, you a) have some knowledge and experience, and b) have the fire in your belly to research to learn more about what you don't understand.
===================================​
Now for the fun:
The first thing I did was to create a new mountpoint the userdata partition. This I made on what is the root filesystem of the device; on a system-as-root device, it would be on the root of the system partition, and on a non-system-as-root device, it would be on the root of the boot ramdisk. I named it userdata/. Accordingly, I edited my fstab.qcom (at etc/fstab.qcom on the vendor partition for my device) to mount the userdata partition on /userdata/ instead of /data/:
Code:
#<device> <mountpoint> <type> <options>
/dev/block/bootdevice/by-name/userdata /userdata <whatever whatever whatever> <you'd probably have to disable options like fileencryption, quota, check (verification), etc.>
and to mount the second profile's directory. Note that it is bind-mounted:
Code:
/userdata/userdata/ /data none bind
Now to switch between the two profiles, you'd switch between the original fstab and the one you just modified.
That is (most of) it. Some things I noticed:
The device would refuse to boot initially. What worked was to backup and wipe my data, boot, create the second profile's directory and copy the contents of the just-created userdata profile into the second profile's directory. In other words, I couldn't run a "first boot" on the second data profile--I had to copy an existing profile into the second profile. I really don't know why this happens.
I suspect that disk quota, filesystem encryption and verification will mess with this (or rather, the other way around). I can't be sure, because I have all three disabled.
Having a shared Internal Storage (/data/media/0/) is convenient. For this, I just bind-mounted that too:
Code:
/userdata/media/0/ /data/media/0/ none bind
This can also be used to easily achieve dual booting on an A/B device, as long as you don't use seamless updates. One ROM per slot can be installed, and the fstab.qcom on one of the vendor partitions can be configured to use the second profile. This way, there would be no need for an external SD card or additional partitions.
I'm pretty sure there will be other hurdles with other devices and other android versions. As I said, I'm just here to share an IDEA, and NOT a foolproof, one-size-fits-all solution. I hope this helps other people make their lives simpler. Please do share your notes on this thread if you manage to get it working on your device!
Its easy to have two roms on one device and its simple,just take a nandroid aof your current rum,now flash another rom an set it up,when u need the other rom just restore your nandroid and so on,i have 4 roms,all fine,lol.
But that's kinda inefficient, don't you think? If you just swap a single file instead of the whole data partition, it's much faster--it takes as long as rebooting + a few milliseconds.
But well, whatever suits you
Hey bro can u pls explain the second code line u mentioned???
varunrocks17 said:
Hey bro can u pls explain the second code line u mentioned???
Click to expand...
Click to collapse
/userdata/userdata/ /data none bind: (this is the line right?)
This bind-mounts the directory /userdata/userdata on /data. /userdata/userdata (directory /userdata under the userdata partition that we previously mounted) is the directory under which the contents of the alternative userdata partition are stored.
Bind-mounting is a means by which a folder can be treated as a device to mount (as opposed to a normal block device or partition). As the mount(8) documentation states, it is a way to "Remount part of the file hierarchy somewhere else."
By this mechanism, the /userdata/userdata folder is made to look like the entire userdata partition. In other words, when you access anything under /data/, you're in fact accessing /userdata/userdata/.
I did something similar to a Jellybean. That is, quite long time ago. Stock fw didn't support encryption. So I made a hack that used cryptsetup and vold.decrypt triggers. That way only framework had to restart. It probably is not that simple anymore...
Anyways, what I learned that it wasn't worth it, so I didn't release it back then. Back then there was a real space shortage and it wasn't wasted like nowadays....
Thanks for that userdata idea that's what I was messing around and. Creating multiple partitions for each rom ...
Btw one question :
Kernel intially mounts vendor then from vendor/etc/fstab.qcom all others are mounted ..?
Or kernel have the predefined vendor system and userdata partition locations ..??
I am really confused here ..
That's why my multi boot was bit messy..
aryankaran said:
Thanks for that userdata idea that's what I was messing around and. Creating multiple partitions for each rom ...
Click to expand...
Click to collapse
Glad I could help
aryankaran said:
Kernel intially mounts vendor then from vendor/etc/fstab.qcom all others are mounted ..?
Or kernel have the predefined vendor system and userdata partition locations ..??
Click to expand...
Click to collapse
On my system-as-root device treble-enabled device, the vendor partition is mounted by the kernel. There is a node in the kernel's device tree blob (dtb) that specifies the vendor mount. When the kernel is fully initialized, it has its own /dev filesystem, using which it mounts the vendor partition. I hope that part is clear.... not sure if I explained it nicely...
Once the vendor is mounted, /vendor/etc/fstab.qcom is read and all the other partitions are mounted from there.
Ok it means it's just the same scenario as it was till Android 7.1.2 that boot image mounts all partitions..
Just difference that kernel now mounts vendor and further processed by fstab ..