[Motorola Droid 4] LuH:
Taken from CM12 thread as this started to become off-topic. The issue I'm trying to address is how to stuff a huge Lollipop ROM directly into internal storage, without creating a virtual slot, to increase system performance and have overall cleaner solution. Original inspiration: [MENTION=5003013]Mentor.37[/MENTION]'s custom Safestrap for unused partitions, which has way too small /data for me unfortunately. (explanation)

This allows you to mount the partitions either as a new storage or to a specific directory only, in other words it does not merge the storages, just adds a mount point next to (or possibly if modified a bit on the top of) other storage. While this may be useful for taking some inherent load off /storage/sdcard0/ (i.e. mounting /dev/block/webtop to /storage/sdcard0/Downloads) for people not swapping their sdcards, it doesn't help in Septfox's intention of enlarging /data/.

I face the same problem as Septfox: I'd love to use the storage intended for running system for it, not virtually mounted storages created in the storage intended for storing media and support data. However, the outline of the storage is intended for way older and less robust system so even the /system/ is not quite enough (667 MB, which tightly fits CM12 with a small GApps package) and /data/ is also not enough for heavier use (3.22 GB). Therefore I would like to merge it with currently unused partitions: maybe join preinstall to system and webtop to data, making both big enough.

One alternative would be to mount the 1.4 GB webtop as /data/app, which currently makes about 2/5 of occupied space of my /data. Is this possible? At which point of system startup is the script in /system/etc/init.d executed (is it done by Safestrap or the ROM itself?), and at which point might the system first need to access /data/app that contains the APKs of user-installed apps? All the really needed stuff (compiled executables) is in the /data/dalvik-cache, right? Here I'm on a really thin ice, don't know much about Android's architecture, so sorry if this is a major bullsh*t - just throwing my idea in :) Technically what I'm talking about is such modification of the script:

#!/system/bin/sh

mount -o rw,remount /data # Not too sure about this
# - depending on whether /data is already rw or not.
# For that I would need to know when is the script
# executed. I'm almost sure this is not necessary
# though. In original script this was done to allow
# writing into /storage/.
mkdir /data/app
#mount -o ro,remount / - unnecessary, see above
#mount -t ext3 /dev/block/preinstall /storage/preinstall
# I don't see any use for small preinstall partition.
mount -t ext4 /dev/block/webtop /data/app
chmod 777 /data/app # not sure about this either,
# probably should be 771

Clean version:

#!/system/bin/sh

mount -o rw,remount /data # Unnecessary?
mkdir /data/app
mount -t ext4 /dev/block/webtop /data/app
chmod 777 /data/app # Possibly 771 instead.

Is that possible to run, or will it bootloop, what do you think?

Even better IMO would be to delete preinstall and webtop and shrink the Stock data down to maybe 200 MB so the original Stock system is still present, preventing the phone from bricking and accommodating Safestrap. The remaining space could be divided between Safe system (say 800 MB) and Safe data (over 4 GB). Are we able to do this somehow, maybe by customizing Safestrap a bit more? Or are partitions in /dev/block locked by bootloader? Also are all these and Internal storage located on the same physical chip, or are there two separate memories in the D4? Attached proposal of repartitioned layout :) Sizes taken from here and here.

Developers and experienced users, I would love to hear your opinion, mainly on whether repartitioning internal storage or at least mounting webtop to /data/app could work on D4. Thanks!

Addition to the original post:

I have a spare D4 with shattered screen and not working SIM slot that I bought for spare parts. Apart from GSM (or telephony altogether? I didn't try, as only option would be emergency call which I don't want to abuse, and we don't have CDMA networks here) it works fine though. I can try meddling with formatting/partitioning - it won't be too big deal if it gets bricked beyond possibility of SBF restore.