data2btrfs (this is DEV status so don't ask how to install - there is (little) linux expirience required)
Update about btrfs dec 15: Still testing btrfs and im REALLY amazed. Battery life has no difference to ext4 but performance is FAR better then ext4. I do still get lags in some cases (like fast! downloads) but this is simply a hardware issue which can not be addressed. Im using a class 2 sd only and i dont think that this can get ANY better. I think btrfs should run like HELL on a class 6+ card.
Update dec 14: Atm i'm using btrfs with "ssd_spread" (for ssd harddisk with older controllers. The controllers in SD should suck compared to some modern SSD so this will effect SD-Cards even more than "ssd" optimization (more info). And im amazed. It is even more smooth than nilfs (maybe less cpu) and so far the smoothest expirence i had with data2sd/data2ext. Even compared to EXT4 without journaling.
1. Btrfs is "copy-on-write" filesystem and i think that "copy-on-write" or logbased (like nilfs) will be the future.
2. Btrfs and nilfs are both better for "old" or "cheap" SSD-Drives because they are optimized for it. While this will decrease the performance of a modern SSD-Harddisk (since they are getting better and better in emulating a rotating device like a classic HD) it will INCREASE the general performance on ssd like an sd-card because their controllers is a lot worse than one of a state-of-the art SSD-Harddisk. So these optimization.
3. MeGoo (a linux made for smartphones) already has chosen it as default even though its still beta and i think they have some good reasons for this.
4. Btrfs has the same (and theoratically it should be even less - tiny) battery consumption. Other then nilfs wich had horrible battery (over 1%/h on its own even when phone was idle). Thats why i moved to btrfs from nilfs.
EDIT: Removed something really stupid xD
Safety concerns about data2btrfs
script: Considering the script i addressed ALL safety conserns that there are at present. This is based on the findings of the SGS devs and mounting directly on /data is even more save then cyanogen's app2sd+ (at least for the desire which unmounts /data - SGS doesn't). Only dalvik-cache is symlinked and a data corruption there is unimportant and can be helped by a simple wipe of the cache. So no concerns about this. (But note: the script is still "young" and there might be still errors - thats why i also don't provide a zip for ext4 yet)
btrfs is indeed still in an experimental state. But speaking FOR MYSELF ONLY (everyone should estimate this on its own) i don't have any concerns. The reasons are:
-experimental state is almost over and i doubt that there are any major bugs present.
-many Linux already use it and its default for MeGoo
-I have backups for all sensible data on my computer (like license keys - this can be lost if you backup already corrupted data with titanium/etc)
How to use it
(experienced linux users who know what they do ONLY)
- (recommended for ~ +20% speed) Delete your old ext partition create a new primary partition if it is not aligned yet. Gparted has a "align to mb" option wich makes alignement increadibly easy. Since 1024kb alignement is enough for sd there isn't anything else you need to care about.
- Make a btrfs partition with your favorite linux distribution (im still a ubuntu noob ) with btrfs utils.
- Make sure you flash a Rom that doesn't need sd-ext for installation (check the META-INF/../update-script for "copy_package XYZ SD-EXT:XYZ" - delete or format sd-ext there isn't a problem you will get an error (like on leedroid) on install but this doesn't matter)
-make sure you have Kernel with btrfs support (see below for this)
Kernels with btrfs support (SENSE ONLY for now)
-NeoPhyTe.x360 's (ext2, ext3, ext4, reiserfs, xfs, jfs, btrfs, nilfs2)
-Coutts99 Kernels (chose the btrfs-test-kernel ofc ;) )
no btrfs support in recovery this means:
-no backup of the sd-ext partition (it isn't ext anymore ;) )
-wont work with ROMs that need sd-ext for installation (some HD roms)
- cyanogen who made app2sd+ in the first place.
- sibere and ownhere who started all the data2sd.
- supercurio and Unhelpful of SGS' Voodoolagfix (#Project-Voodoo on freenode) for their helpfull script tipps.
- Coutts99 and Neophyte for their Kernels.
- woti23 for all those test's in this thread.
- All devs of XDA in generall for all this nice stuff that is done here
Further Plans for the script
- Changing scheduler settings depending on results in the btrfs thread to get the last out of your SD while assuring safety (thanks woti23 for all the testing).
- Trying to add support to delete the ext partition and create it new with an 1024k alignement (~ +20% more speed)
- Mounting /app-cache to /cache or internal data partition (8 MB more RAM since its mounted on RAM)
- Changes for the mount options of the internal YAFFS2 Partition to optimize the speed of the "dalvik-cache" (have to look into YAFFS2 what can be done)
- Adding some lines of code to clear up any present symlinks on first boot to make it ROM upgrade compatible
- Adding e2fsck with check on every boot (script is quick edit of my script for btrfs - no e2fsck yet)
- Other changes based on the results in this or other threads about data2ext/data2sd
- Remove the errors i made ^^
Remark: i moved the data2ext4 script to my other script and set the dev tag again. I also added UBIFS discussion to the title. I also removed the nilfs utils and the data2ext4. The data2ext script can be found here. If someone wants to test nilfs you can PM me (but battery SUCKS incredibly )
(dec 15): One minor change in assigning a variable. Doesn't change ANYTHING in actual behavior but code it's more "logical" (assigning the output of "busybox ls" to the variable instead of the command ^^ d'oh)
(dec 15) Fixed a stupid error that could lead to exit code (2) ....... and uploaded the proper file for btrfs (not the ext one). Sorry.... -.-
(dec 16) Fixed the fix ....
(dec 16) the scripts create now the folder it needs if it is not present yet (sorry i also forgot this in required ... was only there in the ext4 thread ^^)
DISCLAIMER: BTRFS is still under development and thus an EXPERIMENTAL filesystem. Please refer to the btrfs wiki for more information.