Ok, here's something you can try if you qualify yourself as reasonably experienced on tinkering with Android devices.
If you're completely satisfied with solutions like app2external_sd and/or link2sd, or similar applications, you should probably keep using them. If you discover, however, like I did, that they're not complete solutions and instead want the primary storage of the entire /data directory to mount from the external SD card, this may be what you're looking for.
As of this post, this is an ALPHA version, not packaged for end users. If you're experience with Android, are familiar with ADB, have rooted the phone, familiar with Linux command line usage and are completely prepared to restore the phone with either LG's tools or a kdz of the stock operating system as a precaution for your own experiments, then you're qualified to try this. If you're not entirely familiar with these concepts then you should wait for this project to advance, but you may find it interesting to follow.
Read what follows as if you found the notes from an engineers desk detailing an experiment. This explains how it works and how to try it.
NOTE: I said TRY IT. Some are frustrated with the LG devices, F6 and F3 among them, because of the storage problem, and are eager to try solutions. The link(s) at the bottom are EXPERIMENTAL, and the reason they're posted is for experienced users to assist in PROVING them to be viable. If you're more of an end user looking for a quick solution you can install, this is not yet ready for that.
If you are knowledgeable and confident to experiment, then consider this a sincere request to try it and post back with problems, observations and suggestions. The intent is to provide something more suitable for the typical user capable of rooting their phone, but little else.
I have this working on my son's F6 - it can work on yours, or your F3, L9 or most any device with Android 4.0.3 through about 4.2.2, with a really simple and quick move all the way to 4.4.2.
I type fast and, like Pascal once noted, I don't have time to write a short post, so I wrote a long one.
This project was started around Jan 1, 2014, prompted by a Christmas gift of an LG Optimus F6 for my son. While the phone is wonderful, the /data directory is mounted from a 1.27 GByte partition on the internal SD card, which easily fills up (that took all of 2 hours to discover). I tried various solutions, from app2external_sd combined with link2sd, as well as manual experimentation using a shell through adb on the phone. Nothing really works. They help, there's no doubt. You can manage to relocate applications to the point where you free up another 300 to 500 Mbytes, maybe more, but that 1.27 Gbyte partition, mmcblk0p15, still fills up eventually. My son is 12. He's already fetched a 600Mbyte GTA 3 and a 900 MByte GTA San Andreas. It's possible to finagle these into the phone, but that's only a temporary solution. Between my son and my wife there will be over two hundred apps installed, I see it coming. /data/dalvik-cache may need 1 Gbyte just for the dex files.
Well, I'm a software engineer of 30+ years experience, with a long history of Unix and Linux work, so naturally I decided to cobble together a serious solution.
While there is information that "loki" is available to unlock the boot loader of the F6, there are valid reasons for concern using it. Loki exploits a minor flaw in the security method of the boot cycle, allowing a modified image to be booted instead of the approved factory image. The problem with using it, as I discovered, is that at this point support for the F6 is limited to specific carriers and versions of the OS. Loki happily generated an invalid image for my F6 without warning, and the potential for serious bricking of the phone is fairly high. Rumor has it that Android 4.4 will be coming to the F6, and if you rely on loki to unlock the boot loader as a means of solving the storage problem, you may be out of luck for a long while waiting for loki to support version 4.4 on your combination of carrier and version. I support what loki is doing, but I can't see myself using it for this problem.
The solution presented here will still work on the 4.4.x version, without waiting. The technical modification is actually simple. It does rely on the fact that LG leaves the content of /system intact between boots. I suspect they do this because they link pre-installed applications from /data/app to /system subdirectories, and want to be able to update them without updating the system.img stored in ROM. Factory resets, as a result, will restore the content of /system, and therefore remove the modifications proposed here. They are, however, easily re-installed.
I have this working on my son's F6, and the experiments have been repeated on emulators and other devices, including a Kindle Fire first generation on Android 2.3.3 (but I'm not bothering with posts on supporting earlier than 4.0.3 here). It works in all of those situations. Your mileage may vary.
The goal is to provide a source for the /data directory from the external sd card - all of /data, not just links or subdirectory mounts. We are prevented from doing this because the boot loader is locked, and therefore all changes to the important file init.rc and it's cousins will evaporate at each boot. This would be trivial to solve if we could edit the ramdisk.img, or files in other images, but we can't (reliably, IMO).
/data is mounted from a partition of 1.27 Gbytes, /dev/mmcblk0p15 (on the F6). The content of other important directories like /data/dalvik-cache, /data/data (and all it's children) and /data/media are all served from that 1.27 Gbyte partition. It isn't practical to mount other sources over these directories because in the stock configuration (which we're bound to by a locked boot loader) we have no way of performing those mounts until after the Dalvik VM has launched, and critical Android applications are already dependent on the content of these directories.
Early on I tried to mount /data from the external card, which irritates Google's Gapps and it's cousins to the point of repeated pop-up complaints, making the phone unusuable until they're disabled. A soft reboot fixes this, but the F6 is very touchy about soft reboots for some reason. I don't like a soft boot approach either - it's very messy, leaving material in various databases unkempt, sometimes confusing applications.
What is required is a way to fire a shell script before the Dalvik VM launches. Smanager, Universal init.d and similar tools can't do that. They begin execution from within the Dalvik VM, after it's already running.
Outside of altering init.rc, the solution is to replace a single small binary file called app_process found in /system/bin. Links at the bottom for alternate version(s) of this binary were built from AOSP source version 4.1.2_r1, which are indentical from 4.0.3 through the current master branch, 4.4.2 - though I'm going to append one built from the 4.4.2_r1 AOSP source to be certain we're set for the 4.4 update. This modified version of app_process blocks the initializatin of zygote, the name given to the Dalvik VM's process, until a shell script at /system/etc/init.d/zinit.sh is finished executing, if and only if the script exists (otherwise, zygote is launched as it always was).
The solution coincides with another product called Xpose. The key to Xpose is also a modified version of the app_process binary, which provides additional "hooks" for customizing Android when the boot loader is locked, or a custom ROM is undesirable or unavailable.
I noticed the key importance of the app_process binary just before I discovered Xpose, while perusing both init.rc and the AOSP source of Android 4.1.2_r1. This is a tiny file, and a deceptively simple source code. Xpose does not take advantage of the timing of the initialization of the Dalvik VM.
I point all of that out because if you use Xpose you must choose a version of the app_process which is actually a fork of Xpose - so that you get BOTH of these features combined. Installing this solution would otherwise replace Xpose, disabling it. I've posted this with only app_process without Xpose as of this writing, but an Xpose version will appear later.
The original version of the app_process source found at
https://github.com/android/platform_frameworks_base/blob/master/cmds/app_process/app_main.cpp has this clause:
Code:
if (zygote) {
runtime.start("com.android.internal.os.ZygoteInit",
startSystemServer ? "start-system-server" : "");
}
This is what starts the Dalvik engine. This code hasn't changed since 4.0.3 or before, and is very similar to code going back to 1.6 and earlier. This clause is run only once at power on, or on a soft boot if zygote dies. Xpose does not alter this clause. However, I alter it something like this:
Code:
if (zygote) {
if ( access( "/system/etc/init.d/zinit.h", X_OK ) == 0 ) system( "/system/etc/init.d/zinit.h" );
runtime.start("com.android.internal.os.ZygoteInit",
startSystemServer ? "start-system-server" : "");
}
This simple system call, executed on the condition that the script zinit.sh exists and has execute permission, is the entire modification made to app_process under this proposal (Xpose does other modifications). It is therefore conditional - that is, app_process works exactly as always if the script doesn't exist. Readers familiar with C may recognize known objections to the use of access, favoring stat - but they are concerns based on irrelevant security issues in this context. The validity of the objection is the fact that access uses a view of the file's permission in a way that differs from functions which actually open the file. It's possible these two permission profiles differ. However, in this use, the code is running as super user (even if the phone were not rooted, obviously after install) - so the notion is entirely irrelevant. stat would report the same view here, while access is smaller.
What's important is that zygote will NOT be initialized until after the script completes (if it's executed at all), giving us the opportunity to reconfigure a great deal of the operating system without disturbing Dalvik, or Google's Gapps, or anything else known to us as Android.
Installation is merely:
Code:
mount -o remount,rw /system
cp /storage/external_SD/app_process_non_xpose_4.1.2 /system/bin/app_process
busybox chmod a+x /system/bin/app_process
mount -o remount,ro /system
Where /storage/external_SD/app_process_non_xpose_4.1.2 is the modified binary provided for non Xpose compatability (or one of the other versions I'll be appending via links at the tail of this post). Any means of copying app_process into /system/bin is fine.
The remount is required when /system is mounted read only (the default after boot).
Obviously, busybox was assumed in this example...the default version of chmod doesn't support a+x, it takes only octal parameters.
Now, astute readers immediately realize this has nothing to do with storage.
That's correct, this only provides a hook by which we now have the ability to execute script(s) before Dalvik starts using /data. Consider this the installation of part 1 of the solution, the first pre-requisite to making this possible. The key is the ability to use mount while Dalvik is not initialized, which is a condition entirely out of reach unless we can unlock the boot loader reliably.
Now we have to have something to mount. The typical external SD card is formatted in the vfat filesystem, otherwise known as FAT32. Unfortunately vfat doesn't support all of the identities and security data required by Android. For that we must use a linux compatible file system. You could choose ext2, ext4 or whatever you like which is linux compatible, and is supported by Android.
Even many regarding themselves as expert may need reminding that the examples of commands which follow purposely erase the entire SD card. The word "backup" does not suffice to explain what is required if there is so much as 1 byte of material you must preserve. Transfer is, perhaps, a more suitable word. The recipient which stores the content of the SD card you may be re-partitioning will be, for a while, the primary source for that material. If there's anything important, it should be duplicated in a physically separate device. Many may not recognize what hidden files/directories are on the external card. These are commonly given names preceded with a ".", which are only visible when specifically directed for display (that is, ls -la instead of ls -l, or directing Linux GUI file browsers to show all files, including hidden files).
Of distinct importance, however, are the hidden virtual filesystem which may appear on the SD card. These are uniquely invisible. Typically these appear as the result of using "move to phone" or other applications which relocate applications to the SD card. These are difficult to backup correctly. The unfamiliar should not apply. Personally, I just reserve the apk's of applications so that re-installation is trivial.
This is exacty why I warned earlier that this is not a tutorial or instruction, but an engineering discussion on how this can be done. If this content is familiar to you (and most Android developers and Linux/Unix users are), this isn't a problem.
At this point it is assumed that the SD card has no content of importance, as it will be completely eradicated.
You can choose whatever method you prefer to partition the SD card, but from my notes this is a general outline of doing this at the command prompt in a shell, accessed via adb with root access:
On the stock device, observe the mount command (type mount with no parameters).
You'll notice that the external SD card is mounted as a vold device with major/minor numbers 7, 33.
Reveals that /dev/block/mmcblk1 also is 7,33. This is the BASE to the external SD card on the F6 (other devices may differ). When partitioned, the first partition will be mmcblk1p1, partition two (fashioned automatically when present) will be mmcblk1p2, and so on. They appear automatically when the card is partitioned, or are entirely absent if the card is not partitioned.
The external card must be unmounted
Code:
unmount /storage/external_SD
At one point this was refused, so I had to
Code:
mount -o remount,rw /
rm /dev/block/fuse
unmount /storage/external_SD
Fuse will be re-created on reboot, so that's actually harmless.
I used
The SD card can't be partitioned if it's mounted - the block device is busy when it's mounted, Linux will stop you.
I'll leave operation of fdisk to your own Google research. You might prefer an app like Aparted or something. If you use fdisk, be certain you use the "v" command to verify the partition configuration you choose, and use the "w" command to write that to the drive. If you don't "w" (write), it doesn't change the partitions, and if you don't "v" (verify) you can generate an invalid configuration.
If you're disappointed that I don't detail the use of fdisk, then these notes and this project is not yet ready for you to experiment. There will likely be a version, later, more suitable where scripts may do this work for you.
I personally decided upon a 4Gbyte partition and a 26Gbyte parition as partitions 1 and 2 respectively. fdisk automatically creates linux filesystem partitions (type 83). One most manually chose to edit the partition type and choose Win95 FAT32 to create a vfat partition.
This configuration gave me the feature of having an automatically mounted external SD partition of 4Gbytes, while providing a 26 GByte partition for use as a source for the new /data directory.
When all is finished I have 24+ Gbytes available after the basic applications plus about 6 games and few others installed, without any need for app by app fidling with storage configuration or concern about where downloads are going.
In earlier experiments I chose one 32Gbyte partition instead. That works, but the phone behaves as though there is no external SD card (because that requires vfat to work), and occasionally a message appeared indicating the card seemed damaged (because it was expecting vfat).
Creating the partitions doesn't complete the task, though.
You have to create the filesystems, analogous to formatting a disk.
On my 2 partition arrangment I have 3 devices routing to 7, 33:
/dev/block/mmcblk1
/dev/block/mmcblk1p1
/dev/block/mmcblk1p2
The first is the base....you leave that alone after fdisk has done it's work.
The second, mmcblk1p1, should be the vfat partition (it's where the LG expects to find it). So, make the filesystem for it with
Code:
mkfs.vfat /dev/block/mmcblk1p1
Then, depending on the filesystem you prefer, start with
Code:
mkfs.ext2 -m 1 -LExtData /dev/blockmmcblk1p2
the -m 1 is "reserve 1% for superuser". You might have reason to use 2 or 3...Google for research if you need.
The -L creates the label, in this case ExtData, for the filesystem. It's not an important point, your choice prevails.
Now, if you want to use ext4 you can...but there is no mkfs.ext4. For ext4 you must turn the ext2 filesystem into an ext4 filesystem. I left ext2 on mine, it's fully compliant with Android's requirements, but to make this ext4 you use tune2fs. Google will provide the details, but an example command is:
Code:
tune2fs -O extents,uninit_bg,dir_index,has_journal /dev/block/mmcblk1p2
Now, at this point the partitions are ready for mounting. In my own F6, where mmcblk1p1 is the vfat I mount thus:
Code:
mount -o rw -t vfat /dev/block/mmcblk1p1 /storage/external_SD
This is the vfat partition mounted over the same position as the stock external SD card in a stock device. This mount is performed manually during the work, but upon reboot this partition is mounted automatically by the OS, because it is partition 1 and it is in vfat format. If either of these two points are not true, it will NOT automatically mount during boot.
The second partition of my F6 is mounted thus:
Code:
mount -o remount,rw /
mkdir /storage/sdcard_partition2
mount -o remount,ro /
mount -o rw -t ext2 /dev/block/mmcblk1p2 /storage/sdcard_parition2
A little explanation:
Every boot, the /storage directory is RESTORED to contain only two directories, sdcard0 and external_SD card.
Every boot, therefore, a directory for the second partition must be created (it will not automatically mount). /storage is "owned" by the root directory, which is mounted read only. It must be remounted read write in order to create the directory. That's what the "remount,rX" commands are about.
On my card I chose the ext2 filesystem. If you used tune2fs to create an ext4 system, or you want to use yaffs2, your parameter following -t will differ. Google provides, but again I remind readers if this is Greek, you're still just touring the experiment.
Some may inquire, why not just wait and mount /dev/block/mmcblk1p2 over /data when the time comes? That works, and it is more "natural". However, in my own intent, I want access to the storage of the larger ext2 partition for other purposes (whatever that may be in the future), which means I intend to use a bind mount from a directory on the ext2 partition to serve /data.
Ok, the stage is set...we're almost ready for the play.
In manual experiment I created:
Code:
mkdir /storage/sdcard_partition2/.remounts
mkdir /storage/sdcard_partition2/.remounts/data
This creates a directory which will hold the original contents of /data, and eventually serve (ongoing) all purposes of the original /data, but with larger storage (26Gbytes in this example).
I'll leave the appropriate chmod for you to choose, or to Google if you must...but if chmod is foreign to you, wait for a more public release.
The original /data may be of use, for several reasons, but it will eventually be left alone ongoing until some reason comes that I should boot the phone without the external SD card. It can't be unmounted while the phone is running, and mounting over it with empty contents is the same result.
Copying /data to the external card is as simple as:
Code:
cd /storage/sdcard_partition2/.remounts/data
cp -rp /data/* ./
Which takes a minute or so, depending on the size occupied, but it's not a good idea while in a shell. It will work, and maybe suffice, but Android is running. Google has it's databases open, tinkering around. Whatever we copy is going to be read while in use, possible creating SOME databases with invalid content. Most (maybe 98% or more) will copy just fine, but in my experiments Google was left puzzled when booted with a copy made this way. It eventually settles, but to me it's best to make this copy during the newly created opportunity of running scripts in Linux while Dalvik is suspended from initiating.
The idea is to drop some scripts into position, intiated from /system/etc/init.d/zinit.sh. That script, whatever is in it, will be executed by the new app_process binary just before zygote (the Dalvik engine process) is launched.
So, a one time installation script is in order, followed by a script left in place which operates this configuration from then on.
Further, it is important that we should be able to boot the phone in a "stock" fashion at will...that is, with the original 1.27Gbyte partition servicing /data...from mmcblk0p15.
Also, we may have good reason to review the content of the old friend now and then.
So, here's one of the reasons I wanted to mount a directory in the second external partition rather than mount the partition over /data...zinit.sh will call a script from /storage/external_SD/.bootscripts/external_boot.sh, or something to that effect.
The idea is that when zinit.sh fires on boot, if the external card is present, the script umounts /data from the interal source, mmcblk0p15, then mounts /data from the external card at /storage/external_sd/.remounts/data over /data. If the external card is NOT present, or a different card without a script at /storage/external_SD/.bootscripts/external_boot.sh is inserted, then the original /data is left mounted from mmcblk0p15 and the phone operates as a stock device.
The minor catch being that the script in /system/etc/init.d/zinit.sh must check to see if there's a partition at /dev/block/mmcblk1p2 (in my example configuration), and that it mounts correctly as an ext2 filesystem (or whatever fileysystem you prefer, like ext4 or yaffs2), and then check to see if a script is found at /storage/external_SD/.booscripts/external_boot.sh before attempting to execute it.
The script in /system/etc/init.d must, therefore, be fashioned according to your chosen configuration of the external SD card.
While I suppose some mastery of sed and awk could fashion this script from source text (for a proper "consumer" level installer), I'd personally rather use C++ - but that's for later in the project, not this post.
So, imagining for a moment that we're able to fashion a script that runs before Dalvik is active, I explore a few commands which would be of use in such a script.
The first being:
Code:
unmount /data
mount -o remount,rw /
mkdir /storage/original_data
mount /dev/block/mmcblk0p15 /storage/original_data
mount -o remount,ro /
This block is likely to be a part of that which performs the creation and mount of /storage/sdcard_partition2 mentioned above.
At which point the original content of /data, as viewed on the stock running phone, is visible at /storage/original_data.
The new proposed source for /data will be visible at /storage/sdcard_partition2/.remounts/data, while /data is actually empty at the moment.
As such, for a one time configuration script during boot:
Code:
cp -rp /storage/original_data/* /storage/sdcard_parition2/.remounts/data
Would create a duplicate of the original data, with ownership and permissions duplicated, and links duplicated.
This means that LG and the service provider's links into /system/.... for the pre-installed applications would already be correctly set.
This leaves two interesting potential issues. There may be links created by link2sd or applications like it. They may have pointed to targets in /storage/external_SD/... or to hidden virtual filesystems the way "move to phone" does, depending on what application was used. If the 4Gbyte partition is restored with the old content of the external_SD, links would be restored, but the virtual filesystems are more difficult. I avoided the virtual filesystem problem by simply re-installing the applications, while the links I manually established earlier were served by restoring content to /storage/external_SD.
When the copy is complete
Code:
mount -o rw,bind -t ext2 /storage/sdcard_partition2/.remounts/data /data
supplies the needed /data directory from the external SD card's second partition, an ext2 filesystem in my example (adjust to suit your choice).
The script which performed the copy above would then be removed, replaced with a script that just performs the mount over /data for subsequent boots.
Additional scripts or an app may be required for special situations. The following describes what that's about.
Configuring and using the device this way presents us with the following attributes:
The original /data is known as /dev/block/mmcblk0p15, mounted as /storage/original_data. It will retain older content, but will not be updated when applications update.
The "new" /data is served from /storage/sdcard_partition2/.remounts/data, is therefore visible from two perspectives (though .remounts is technically a hidden directory, it's very easy to get to it), and will receive application updates.
This means there is an opportunity, on occasion, to review /data (as mounted from the external card), compare that to /storage/original_data, and copy updated content to it, including refashioning links that may have changed (should they even exist).
If the phone is booted without the external card, the older versions of the applications would be used...then perhaps updated, if given the opportunity.
If the script in /storage/external_data/.bootscripts/external_bootscript.sh is renamed, a reboot would leave the original /data (from /dev/block/mmcblk0p15) in place, operating on older content, but leaving the external card available - /storage/original_data would not exist, but /storage/external_SD and /storage/sdcard_partition2 would - or could - be mounted and useable, just not used by Dalvik (or Android).
Now to some more experimental notes. I've not written the scripts described above, entirely (especially the copy of the /data partition). Instead, I did this:
In place of the external_boostscript.sh
The reason was simple: I was (and still am) experimenting, and if you're considering it, you'll want this feature too.
This sleep is in the external script, which means /system/etc/zinit.sh fired, mounted the external partition 2, but then slept for 2 hours.
Zygote, and therefor the Dalvik runtime...everything we think of as Android...is suspended from initializing. The phone may be showing a black screen, or a boot logo...but otherwise seems stuck.
Through adb, a shell allows me to manually arrange what I want for experiment.
For example, I manually copied the original /data directory to the new partition on the SD card.
I then manually unmounted /data (from /dev/block/mmcblk0p15, the original) and then mounted that duplicate from the external card over /data.
When I'm ready to try it out, I then examine the ps report (for those not familiar, this is a list of all processes). From that I find the pid of the sleep which is hanging there, then kill it. The suspense is over. Android to boots (because zygote is no longer blocked by the sleep), but now in my new, manually arranged configuration (a one time experiment). A reboot returns things to "normal".
Well.....normal after a 2 hour boot sleep. You'll want to use the shell to remove that script (this caught me twice).
Further, it is not absolutely required that you format the SD card to experiment.
If you've read this far you're probably going to try this at some point, even if you have to study a bit to figure out what each of these command lines are.
So...how, if the SD card's stock vfat is incompatible with the concept of servicing /data?
A virtual filesystem.
Here's how.
Make a directory on the external card....in the vfat system.
cd to it.
Now consider these notes.
Code:
dd if=/dev/zero of=filesys_data bs=32768 count=65536
This creates a 2 Gbyte file on the sdcard called filesys_data, filling it with zeros. Alter count such that 32768 * count = size you want.
This will be your virtual filesystem. It can evaporate at the mere "rm filesys_data".
I discovered that on the F6 the maximum is 2Gbytes. VFAT is supposed to be able to handle 4Gbyte files, but on the F6, they evaporate on reboot. It works as long as you don't reboot, but there's some kind of bug involved. 2Gbytes is the maximum that actually worked for me. At least that's a little larger than the 1.27 Gbyte source, the size of /data.
To use it, you need a node.
Code:
mknod /dev/block/filesys_data b 7 101
This creates a node for a block device named filesys_data (you may substitute at will). Google for more info if you need. Think of it as mounting a socket on a wall to plug things into.
Wire up the socket with losetup:
Code:
losetup /dev/block/filesys_data /storage/external_SD/whereveryouputit/filesys_data
Adjust to your choices...whatever directory you create to store filesys_data (or whatever name you preferred). Losetup wires the socket to the source, in this case the blank file you created.
Now, the socket refers to a blank fake disk, represented by the file filesys_data, in whereeveryouputit.
We essentially plug in a piece of tech gear to prepare it with:
Code:
mkfs.ext2 -LExtData -m 1 /dev/block/filesys_data
mksf.ext2 creates an ext2 filesystem (fully Linux compatible) using the socket (well...it's a node) /dev/block/filesys_data, which is wired to the blank file create whereeveryouputit/filesys_data.
You can use tune2fs to make it ext4 if you prefer.
It will be as large as the file you created ( bs * count ).
It can now be mounted as if it were a separate SD card, formatted as ext2 (or 4 if you chose).
Code:
mount -o remount,rw /
mkdir /storage/fake_data
mount -o rw -t ext2 /dev/block/filesys_data /storage/fake_data
mount -o remount,rw /
We must have a directory to mount over, and we have to make it since /storage is always "restored" on boot, and since /storage is on a read only filesystem from root, we have to remount /.
At this point /storage/fake_data is an ext2 (or ext4 if you made that) filesystem, hosted as a virtual disk created as a blank file on the SD card.
Note, if you used tunefs to make this ext4, your -t parameter will be ext4 not ext2.
This allows you to experiment WITHOUT having to reformat the SD card.
You can now make directories inside /storage/fake_data....like .remounts/data...with which to experiment. It's a Linux filesystem, so it understands identities and permissions that vfat does not.
Yes, you can copy all of /data into it and use THAT as the primary source for /data, as in the previous discussion. It will only be 2Gbytes, but it's larger than 1.2Gbytes and lets you prove this works before you commit to partitioning and re-formatting your SD card.
This is closely related to what happens when you use the "move to phone" feature.
Now for the rest of the story
I have this working, but there's a complaint....perhaps the last piece of the puzzle to solve.
The device boots fine, runs fine...but it complains that identies on the /data directory are not "synchronized"....I believe this is simply an unattended detail as of this post. I'll continue studying tonight. It's a minor flaw, but has to be fixed (figured out) before it can be fashioned into a solution for a wider public. I just ignore the warning - the phone and all software, new installs - etc - work fine.
This represents the state of the experiment as of Jan 24, 2014...it's a part time adventure.
The binary for app_process version 4.1.2_r1, like the phone, which works from 4.0.3 through 4.2.2 (tested)...should work on 4.4.2, but I'll verify later, is at this link:
http://www.ih-palladian.com/app_process_4_1_2_r1.gz
BTW, if you didn't recognize that you have to gunzip that before installing it, you may not be ready to try this.
If you read the above, you'll know what to do with it.
Please post with experimental results and observations.