Database Users

Quadrant & DHD

Hi there,
as you might know, the SGS has very high quadrant scores.
This is due to people using the lag fix, which effectively disable the fync() called on the quadrant's database write operation and is cheating.
A SGS actually scores around 1800 at quadrant "without cheating" (cheating: http://android.chemlab.org/quadrant-rape.png)
Since all the noob web blogs and so-called journalists all use the quadrant table to show and decide if a phone is faster than the others, it would be interesting to apply the same cheat to the DHD and submit the quadrant score.
I would be interested in the results, both the number, but also the reaction of those various rather stupid blogs (hi engadget etc ;p)
As I have a SGS and no DHD (and do not plan to replace the SGS by one! ha!) here's how to proceed, prolly need a few adjustements to work on the DHD (as root, need a rebooted phone, adb of course)
At your own risk!
- create a big file:
dd if=/dev/zero of=/data/data.ext2 bs=1024 count=1048576
-create the loopmount node:
mknod /dev/loop0 b 7 0
-make it look like a real disk:
losetup /dev/loop0 /data/data.ext2
-format it
mkfs.ext2 /dev/loop0
-shuffle stuff around:
mkdir /data/data1
mount -o rw,noatime,nodiratime /dev/loop0 /data/data1
cp -r /data/data/ /data/data1/
mount -o bind /data/data1/data /data/data
cp -r /data/dalvik-cache/ /data/
mount -o bind /data/data1/dalvik-cache /data/dalvik-cache
If you reboot, it should still work alright without the cheat but you'll lose any new data between the cheat "activation" on the reboot of course.
Once enabled just run quadrant and check the score.
to disable, reboot and delete /data/data1 and /data/data.ext2
Once again, at your own risk, you might brick your phone etc doing this. Still would be interesting/fun to see.

SGs has around 1000 with stock fw...

DANGER
bilboa1 said:
Hi there,
as you might know, the SGS has very high quadrant scores.
This is due to people using the lag fix, which effectively disable the fync() called on the quadrant's database write operation and is cheating.
A SGS actually scores around 1800 at quadrant "without cheating" (cheating: http://android.chemlab.org/quadrant-rape.png)
Since all the noob web blogs and so-called journalists all use the quadrant table to show and decide if a phone is faster than the others, it would be interesting to apply the same cheat to the DHD and submit the quadrant score.
I would be interested in the results, both the number, but also the reaction of those various rather stupid blogs (hi engadget etc ;p)
As I have a SGS and no DHD (and do not plan to replace the SGS by one! ha!) here's how to proceed, prolly need a few adjustements to work on the DHD (as root, need a rebooted phone, adb of course)
At your own risk!
- create a big file:
dd if=/dev/zero of=/data/data.ext2 bs=1024 count=1048576
-create the loopmount node:
mknod /dev/loop0 b 7 0
-make it look like a real disk:
losetup /dev/loop0 /data/data.ext2
-format it
mkfs.ext2 /dev/loop0
-shuffle stuff around:
mkdir /data/data1
mount -o rw,noatime,nodiratime /dev/loop0 /data/data1
cp -r /data/data/ /data/data1/
mount -o bind /data/data1/data /data/data
cp -r /data/dalvik-cache/ /data/
mount -o bind /data/data1/dalvik-cache /data/dalvik-cache
If you reboot, it should still work alright without the cheat but you'll lose any new data between the cheat "activation" on the reboot of course.
Once enabled just run quadrant and check the score.
to disable, reboot and delete /data/data1 and /data/data.ext2
Once again, at your own risk, you might brick your phone etc doing this. Still would be interesting/fun to see.
Click to expand...
Click to collapse
DO NOT CARRY OUT THESE INSTRUCTIONS, YOU WILL MESS UP YOUR DHD.
Please do not post commands if you don't know what you are doing. Fool

bratfink said:
DO NOT CARRY OUT THESE INSTRUCTIONS, YOU WILL MESS UP YOUR DHD.
Please do not post commands if you don't know what you are doing. Fool
Click to expand...
Click to collapse
i think if he's confident in it working he should go ahead. I'd be interested to see if the DHD can achieve scores similar to the SGS.

bratfink said:
DO NOT CARRY OUT THESE INSTRUCTIONS, YOU WILL MESS UP YOUR DHD.
Click to expand...
Click to collapse
After a reboot the only difference will be a huge file /data/data.ext2 wasting space on the internal storage. Apart from that there is no change.

Please note:
- 1700 is without cheating, not "without lagfix". 1700 (in fact sometimes I score 1800) is with ext4 as native filesystem. Using "cheat" which is the most popular lagfix (it's slower than the real fix too...) you get 2000, 2500, 3000 even sometimes
- I did put warnings, that you've to know what you're doing, will robinson but if you do then you know its no big deal and how to recover if you mess things up somehow

Rolly-eyes
Yes i understand exactly what the commands do. But we are using busybox (without a kernel with ext2 support) to create the ext2 partition, thus once the phone has rebooted their will be a 1gb ext2 block in data/data. However as we havnt flashed another kernel that doesnt have ext2 support we cannot recognise ext2 (only yaffs2). And seeing as we dont have Odin like the sgs has without a proper recovery image (and amon_ra doesnt touch interal file formats) then we would not be able to regain the 1gb and bascially will be screwed. So yea do it if you want. And il buy ur HD brick of you for a 10a

bratfink said:
) then we would not be able to regain the 1gb and bascially will be screwed. So yea do it if you want. And il buy ur HD brick of you for a 10a
Click to expand...
Click to collapse
Untrue.
Just reboot and delete the 1 Gb file created with dd.
This is just a regular file that has been loop-mounted.
btw, if you REALLY want to cheat, make a ramdisk and dd the file in there (you can afford a 256/384 Mb file since the DHD sports 768 MB RAM).
How's THAT for speed?
Arrr!
^^
Here's a quick reminder how to achieve just that:
mount -t tmpfs none -o size=390m /data/data1
continue with the instructions from post #1 (but count the blocks for 384 MB, not for 1 Gb)
;]

adwinp said:
Untrue.
Just reboot and delete the 1 Gb file created with dd.
This is just a regular file that has been loop-mounted.
btw, if you REALLY want to cheat, make a ramdisk and dd the file in there (you can afford a 256/384 Mb file since the DHD sports 768 MB RAM).
How's THAT for speed?
Arrr!
^^
Here's a quick reminder how to achieve just that:
mount -t tmpfs none -o size=390m /data/data1
continue with the instructions from post #1 (but count the blocks for 384 MB, not for 1 Gb)
;]
Click to expand...
Click to collapse
'
Epic ramdisk would be epic. People need to realize that taking benchmark numbers at face value is stupid.

jords12 said:
'
Epic ramdisk would be epic. People need to realize that taking benchmark numbers at face value is stupid.
Click to expand...
Click to collapse
I always find this funny.
In any case, there's no way a regular user would be able to FULLY harness the power today's (1 GHz / 512+ MB RAM) smartphones.
Dual cores and + might come in handy if you're running a second OS in the background (for example, debian/ubuntu or gentoo in a chroot), with active services like ftp/ssh etc...

[Patch] OpenRecovery with ext4 support patch

How to install:
Just unzip to your /sdcard
http://xt720.ru/Files/Patchs/or-147-xt720-fix2.zip

my recovery alrealy support ext2,3,4, nilfs2 (6 month ago)
if you want to add filesystem support edit switch.sh (insmod your modules) and edit to
echo "/dev/block/mmcblk0p2 /sddata auto defaults 0 0" >> /etc/fstab

echo "/dev/block/mmcblk0p2 /sddata auto defaults 0 0" >> /etc/fstab
We already have it in switch.sh.
But thanks! =)

Just curious: what changed in open_rcvr.STR?

fjfalcon said:
echo "/dev/block/mmcblk0p2 /sddata auto defaults 0 0" >> /etc/fstab
We already have it in switch.sh.
But thanks! =)
Click to expand...
Click to collapse
i edit this part
#app2ext partition on sdcard
if [ -b /dev/block/mmcblk0p2 ] ; then
mkdir /sddata
insmod "$MODPATH/jbd.ko"
insmod "$MODPATH/ext3.ko"
insmod "$MODPATH/ext2.ko"
insmod "$MODPATH/crc16.ko"
insmod "$MODPATH/jbd2.ko"
insmod "$MODPATH/mbcache.ko"
insmod "$MODPATH/ext4.ko"
insmod "$MODPATH/nilfs2.ko"
echo "/dev/block/mmcblk0p2 /sddata auto defaults 0 0" >> /etc/fstab
#e2fsck -p /dev/block/mmcblk0p2
fi
i remove e2fsck for nilfs2

#chek linux version
LVER=`uname -r | awk '{split($0,a,"-"); print a[1]}'`
MODPATH="/lib/modules/$LVER"
also i add it
it will auto recognize kernel's version and auto mount current modules

I took your OpenRecovery and added/fixed some things:
'Power Off' menu option
'Toggle Display Brightness' menu option (to reduce battery drain--alternates between bright/dim)
Fixed nandroid backup all (by hiding the partitions that don't work)
Fixed 'Wipe Dalvik Cache'
Renamed 'Applications Menu' to 'Utilities'
Added a symbolic link: /sd-ext -> /sddata
Updated e2fsck to a 1.41.10 (for ext4 support)
Added 'SD Card Utilities'
'Scan FAT partition for errors'
'Scan ext partition for errors'
Can convert ext2->ext3, ext2->ext4, ext3->ext4 (requires ROM support)
'Save diagnostics to /sdcard/sdcard-info.txt' for debugging
Eventually this will also manage the app/link2sd directories
Github: https://github.com/Mioze7Ae/openrecovery_xt720
EDIT: updated with statically-compiled fsck_msdos, tune2fs, e2fsck, and mke2fs from the CM6.3.0 source

Mioze7Ae said:
I took your OpenRecovery and added/fixed some things:
'Power Off' menu option
'Toggle Display Brightness' menu option (to reduce battery drain--alternates between bright/dim)
Fixed nandroid backup all (by hiding the partitions that don't work)
Fixed 'Wipe Dalvik Cache'
Renamed 'Applications Menu' to 'Utilities'
Added a symbolic link: /sd-ext -> /sddata
Updated e2fsck to a 1.41.10 (for ext4 support)
Added 'SD Card Utilities'
'Scan FAT partition for errors'
'Scan ext partition for errors'
Can convert ext2->ext3, ext2->ext4, ext3->ext4 (requires ROM support)
'Save diagnostics to /sdcard/sdcard-info.txt' for debugging
Eventually this will also manage the app/link2sd directories
Github: https://github.com/Mioze7Ae/openrecovery_xt720
Click to expand...
Click to collapse
Awesome nice wok man

The SD Card Utilities aren't working if CM6 isn't installed. I need to find a tune2fs that is statically linked. I thought this one was, but I was wrong.
Edit: fixed now in -fix4

What would it take to incorporate these changes into Androidiani OR?

I compiled static binaries for e2fsprogs and fsck_msdos and updated the zip. I should be working now. http://forum.xda-developers.com/showpost.php?p=16812349&postcount=7
3rdstring said:
What would it take to incorporate these changes into Androidiani OR?
Click to expand...
Click to collapse
Some of these changes are pretty easy. Others are a little more involved. You can look at the diffs in github and port ones that you'd like. Eventually I'd like to merge the functionality of both but I'm focusing on OR for now. You can look at what went into each change by looking at the "Commits" tab at github and then clicking on the commit number on the far right side for a particular change and you'll see what changes were made to which files. For example this is the Toggle Display Brightness change.

I can't get neither one of my sdcards ext4 to mount. I wonder if it might be cause I started with CM6.3? Instead of upgrading from CM6.1 to CM6.3? Just a thought since some of us can and can't mount ext4

LibertyMonger said:
I can't get neither one of my sdcards ext4 to mount. I wonder if it might be cause I started with CM6.3? Instead of upgrading from CM6.1 to CM6.3? Just a thought since some of us can and can't mount ext4
Click to expand...
Click to collapse
Can you install the *-fix4 openrecovery and use
OR > SD Card Utilities > Save diagnostics
And then post the /sdcard/sdcard-info.txt?
Do you have a nandroid of your ext2 partition? If so, try restoring it and the using SD Card Utilities to convert it to ext4.
Sent from my MilestoneXT720 using XDA Premium App

Mioze7Ae said:
Can you install the *-fix4 openrecovery and use
OR > SD Card Utilities > Save diagnostics
And then post the /sdcard/sdcard-info.txt?
Do you have a nandroid of your ext2 partition? If so, try restoring it and the using SD Card Utilities to convert it to ext4.
Sent from my MilestoneXT720 using XDA Premium App
Click to expand...
Click to collapse
Yeah I will post the /sdcard/sdcard-info.txt here but it says the same as what fjfalcon was quoting. And yes I do have a Nandroid of ext2 but never tried to restore it yet. I will try now...

L'enfer c'est les autres...

Mioze7Ae said:
L'enfer c'est les autres...
Click to expand...
Click to collapse
Hell is other people? lol
***Here it is View attachment sdcard-info.txt

Are you referring to the info.txt that fjfalcon posted in the CM6 thread? The commands I gave there weren't correct. In any case the sdcard-info.txt produced by *-fix4 are much expanded and look quite different... I can't find any other post by fjfalcon...
Sent from my MilestoneXT720 using XDA Premium App

Mioze7Ae said:
Are you referring to the info.txt that fjfalcon posted in the CM6 thread? The commands I gave there weren't correct. In any case the sdcard-info.txt produced by *-fix4 are much expanded and look quite different... I can't find any other post by fjfalcon...
Sent from my MilestoneXT720 using XDA Premium App
Click to expand...
Click to collapse
Oh sorry Mz didn't mean to make you look for it, I was talking about when he was saying how some aren't mounting. Anyway I posted it above your last post. I have my ext2 restored. I will try to convert it tomorrow. thanks man.

LibertyMonger said:
***Here it is View attachment 694819
Click to expand...
Click to collapse
Ok, try creating an empty /sd-ext/app|/sddata/app directory and reboot. Then go back to OR and recreate the sdcard-info.txt

Mioze7Ae said:
Ok, try creating an empty /sd-ext/app|/sddata/app directory and reboot. Then go back to OR and recreate the sdcard-info.txt
Click to expand...
Click to collapse
I'm sorry not sure what you mean here "empty /sd-ext/app|/sddata/app directory"
app|?
I think I got it... rebooting...

[TOOLS+HOW TO] Disable and enable journaling in internal ext4 Partitions

It is seen that ext4 with journaling off is faster than any file system but is slightly less reliable. I have successfully removed journaling from my file system and have found no problems. I see a noticeable difference in performance as well. Also Quadrant score jumped up by 100 - 200 points.
Journaling is an ext4 filesystem log service and it involves using memory and data.So disabling journaling means that memory and data used for maintaining this service are no longer used and are available for other processes. Journaling is required in computer hard drives as a precaution for data loss in situations like unclean shutdown in power outage. And I don't think mobile phones which use flash drives ever require journaling.
Credits to hardcore for the tutorial here and to chris41g for the following idea.
Here are the scripts with cwm flashable zips I made to automatically convert a journaling ext4 to non-journaling ext4 and vice versa(to make things easier).They will work on custom kernels with ext4 support.
How to flash
Flash Journaling disabler via cwm manager or cwm recovery to disable journaling.
Flash Journaling enabler via cwm manager or cwm recovery to enable back journaling.
To disable ext4-journaling- Download journaling disabler here
To enable ext4-journaling- Download journaling enabler here
To check whether journaling is enabled or disabled type in adb or terminal after flashing-
Code:
# /data/tune2fs -l /dev/block/stl12 | grep features
If "has_journal" is present then journaling is present,i.e,output is
Filesystem features: has_journal resize_inode filetype extent sparse_super large_file
If "has_journal" is absent then journaling is absent,i.e.,output is something like this
Filesystem features: resize_inode filetype extent sparse_super large_file

WARNING: This procedure is risky and may result in loss of data
MANUAL TUTORIAL TO DISABLE JOURNALING credits hardcore
1. Make a backup of your data using cwm.
2. Download the tune2fs zip attached to this post, extract it and copy the extracted tune2fs to /data using root explorer or adb.
3. Go to adb shell and type
Code:
$su
#mount | grep ext4
This will give something like this
/dev/stl14 on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,barrier=0,nobh,data=ordered,noauto_da_alloc)
/dev/stl13 on /data type ext4 (rw,nosuid,nodev,noatime,nodiratime,barrier=0,nobh,data=ordered,noauto_da_alloc)
/dev/stl12 on /system type ext4 (ro,relatime,barrier=0,nobh,data=ordered,noauto_da_alloc)
/dev/block/mmcblk0p2 on /system/sd type ext4 (rw,noatime,nodiratime,barrier=1,data=ordered,noauto_da_alloc)
4. We have to remove journal from the above partitions,i.e., /cache , /system and /data
So,starting with /cache the following procedure will be repeated for each partition.
a) Checking the partition
Code:
# /data/tune2fs -l /dev/block/stl14 | grep features
The output will be
Filesystem features: has_journal resize_inode filetype extent sparse_super large_file
Note the has_journal flag. We have to remove this flag.
b) fsck the partition
Code:
e2fsck -f /dev/block/stl14
Output will be-
WARNING!!! Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.
Do you really want to continue (y/n)?
Answer yes.If after that it asks to alter the file system you may press ctrl+c
c) Remove the journal
Code:
# /data/tune2fs -O ^has_journal /dev/block/stl14
(this is a capital "O"!)
d)Check whether journaling was removed
Code:
# /data/tune2fs -l /dev/block/stl14 | grep features
Output should be like
Filesystem features: resize_inode filetype extent sparse_super large_file
So the has_journal flag is now removed.
5) Repeat the procedure for /data and /system partitions
by replacing in the above codes /dev/block/stl13 and /dev/block/stl12 respectively
6) After you have removed journaling from all partitions- reboot.

Better if rom cooks have ext4 with journaling disabled natively, but I guess it's based on opinion..

consegregate said:
Better if rom cooks have ext4 with journaling disabled natively, but I guess it's based on opinion..
Click to expand...
Click to collapse
It would be good...by the way, I have now made cwm flashable zips to automatically disable and enable journaling,hope it works.

Nice guide skynet .
Sent from my Ultima Weapon© using XDA App

Much easier now. Disabled journal for the time being, seeing if there's a difference in normal usage.

What are the requirements to make this work? I tried it on my KPN with internal ext4 partition. Installed it via CWM but installation was aborted.
Sent from my GT-S5830 using XDA App

I tried and it worked well. I will use this for my rom and give u credit. Tks u so much

Stupid me I installed the other zip file . Now it works .
Sent from my GT-S5830 using XDA App

I don't actually see any performance boost , but I did get a boost in quadrant scores .
Journaling enabled:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Journaling disabled:
Sent from my Ultima Weapon© using XDA App

EmoBoiix3 said:
I don't actually see any performance boost , but I did get a boost in quadrant scores .
Sent from my Ultima Weapon© using XDA App
Click to expand...
Click to collapse
I am not a quadrant fan but thanks for the scores. I went for no journal method because Journaling is filesystem log service and it involves using memory and data.
So disabling journaling means that memory and data used for maintaining this service are no longer used and are available for other processes. And I don't think mobile phones ever require journaling.

Thanks, flashable zip working.

Thanks. The zip is working and my battery usage 'looks nice' so far.
Sent from my GT-S5830 using xda premium

skynet28 said:
I am not a quadrant fan but thanks for the scores. I went for no journal method because Journaling is filesystem log service and it involves using memory and data.
So disabling journaling means that memory and data used for maintaining this service are no longer used and are available for other processes. And I don't think mobile phones ever require journaling.
Click to expand...
Click to collapse
No , thank you for making this

Which is why you don't need ext4 for sdcards, journaling on it is a waste of power.

consegregate said:
Which is why you don't need ext4 for sdcards, journaling on it is a waste of power.
Click to expand...
Click to collapse
Yes I agree..sdcard ext4 partition is overkill.Ext2 is enough.
But Ext4 in internal partitions is useful because of its unique features like Improved timestamps,Multiblock allocation,faster file system checking which are important for regular and critical system applications and services. But we make sdcard partition for apps which are not system critical and thus not really affect performance .
So I think ext4 without journaling in internal partitions and ext2 in sdcard is the way to go

Will this work on sgs?

burakgon said:
Will this work on sgs?
Click to expand...
Click to collapse
You can disable journaling in any ext4 file system but here the method is specific for galaxy ace since partitions are different on different phones.So in the tutorial you have to replace the partition location with SGS ones. Better look in your own forums.Hardcore had written the original tutorial.
The cwm flashable files made by me are for galaxy ace only.

Skynet28,
I tried to disable journaling using your zip file but it was only successful for two of my partition.
You can refer to the output from terminal:
$ export PATH=/data/local/bin:$PATH
$su
#/data/tune2fs -l /dev/block/stl14 | grep features
Filesystem features: resize_inode filetype extent sparse_super large_file
# /data/tune2fs -l /dev/block/stl13 | grep features
Filesystem features: has_journal resize_inode filetype needs_recovery extent sparse_super large_file
# /data/tune2fs -l /dev/block/stl12 | grep features
Filesystem features: resize_inode filetype extent sparse_super large_file
#
I tried doing it manually, but my Ace crash and I had to reformat my Acr.
Sent from my GT-S5830 using xda premium

Hi,
This worked great on my ace running stock XWKPN 2.3.3 using cf-root kernel b-80 and ext4 partitions.. hopefully see some speed boost...
Thanks for zips !

[GUIDE][Noob-Friendly][adb] How to avoid Superbrick // How to revive your bricked Tab

HOW TO AVOID BRICKING YOUR TAB
The best advice I can give to people who haven't bricked their tab (already?^^) : DO NOT EVER WIPE ANYTHING WHILE RUNNING STOCK 7.7 ROMS
Here is what to do in order to flash a custom rom safely when coming from stock :
- Flash the latest cwm with ODIN
- Do NOT wipe anything
- Flash the custom rom of your choice
- Reboot recovery
- Wipe what you need to wipe
- Re-flash the custom rom
- flash the gapps or whatever
- Reboot, done.
Ok guys, I'm seeing more and more people bricking their 7.7 and, being one of the unlucky owners of a bricked p6810, I understand how stressful and annoying it can be.
I've been reviving my tab like a hundred times using this technique, as you'll most likely have to re-do that whole process everytime you wanna flash something.
There are two ways of reviving from superbrick I know of :
- The first is to flash a PIT file with ODIN that will repartition your tab for you.
I will not cover this method as hg42 already wrote a very detailed tutorial about this. This tutorial is about Galaxy Note but you can appIy it to our 7.7 and you'll find PITs for P6800 there. I will soon make pits for P6810 using the scripts provided in hg42's guide.
- The second way is to repartition your tab manually through adb. This is the method I'll try to teach you here.
Let's first be very clear :
- This won't get your tab back in its former state
- Your internal storage will shrink by a lot
- All your data will be lost
- No guarantee it works for you
- You'll most likely have to do that every time you flash
- Your tab might rebrick itself after some days, so you'll have to do this again, get used to it.
- If you can get Samsung to repair your tab then go ahead
- I'm not responsible for any further damage made to your tab
- You need a computer for this tutorial
Ok, you read the above carefully ? You are ok with it ? then let's begin !
Using the Android Debugging Bridge (adb) to revive your tab
Setting up your environment
Prior to anything, you need to download and install the android sdk, I won't cover the installation here, it's explained on developer.android.com and there are plenty of guides on how to get adb and the sdk on xda.
Make sure you install the platform-tools in the sdk manager.
Ok now I assume you got the sdk installed, so let's move on to the serious things.
1) How to open an adb shell ?
First, you're going to need the latest ClockWorkMod Recovery (a.k.a CWM), download and instructions on locerra's thread here
Then boot your tab in recovery (Maintain power+volume up buttons) and plug it into your computer via usb.
Then do the following :
a- On Windows
Navigate to the directory where you installed the sdk, and open the folder called "platform-tools" (e.g : go to C:\android-sdk\platform-tools if your sdk is installed in C:\android-sdk)
Press shift and do a right clic on an empty space in the folder, then select "open a command prompt here" (or something like that).
b- On Linux
Open a terminal window (ctrl+T)
Let's assume you put the sdk in a folder called "android-sdk", located at the root of your home folder (~/android-sdk).
Then you have to enter this in the terminal :
Code:
cd ~/android-sdk/platform-tools
So now, all the rest of the commands you'll have to enter are the same on windows and linux, as the adb shell will actually be running in your tablet.
2) Meet a new friend, he's called parted.
First, we are going to use parted to take a look at our partitions and their file systems, and eventually replace the corrupt partitions with clean, freshly created ones.
Then, you'll meet your other very good friend with a barbarian name : e2fsck (e2 stands for ext2, and fsck for file system check. Not that barbarian finally is it ?). He will check your filesystems and fix the possible errors they got.
Ok now we've made the presentations, let's go !
First make sure you read the following :
In the code boxes of this tutorial, there are symbols at each line start, DO NOT COPY IT with the rest of the command ! :
-the "$" represents your bash shell or command prompt
-the "#" represents the adb shell
-the"(parted)" represents the (parted) shell
-Each end of line means "press Enter".
-The partitions numbers are not the same on p6810 and p6800 (please report to this reference), so there will be two code boxes in the examples, one for p6810 and one for p6800, it's indicated in bold red but make sure you don't mix it up, that could screw your tab even more.
Ok here we go !
Issue the following in your terminal/command prompt :
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) print
The output should look like this :
>>> P6810 <<<
Code:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 209MB ext4 CACHE
8 264MB 1137MB 872MB ext4 FACTORYFS
9 1137MB 15.3GB 4163MB ext2 DATAFS
10 15.3GB 15.7GB 470MB ext4 HIDDEN
11 15.7GB 15.8GB 8389kB FOTA
>>> P6800 <<<
The start/end values are wrong, please give me your p6800 output so I can update this.
Code:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 209MB ext4 CACHE
8 3054MB 3926MB 872MB ext4 MODEM/RADIO (not sure as I don't own this model)
9 264MB 1137MB 872MB ext4 FACTORYFS
10 1137MB 15.3GB 4163MB ext2 DATAFS
11 15.7GB 15.8GB 8389kB HIDDEN
12 15.8GB 15.9GB 8389kB FOTA
The superbrick MMC_CAP_ERASE bug that affects our tab apparently only corrupts the /system and /data partitions (sometimes, /cache can also get corrupt in the process, I cover this in the last part of this guide, "extra cases").
Your emmc chip on which resides those /data & /system partitions is corrupt at some places.
To give you an example, think of it as a chain of dashes :
Code:
-----------------------------------------------------
This dash chain is divided in two parts (our /system and /data partitions), I'll symbolize their length with "[]" for /system and "()" for /data :
Code:
[----------](-------------------------------------------)
So that's how it was on your tab before brick, but now it's bricked some blocks (the dashes "-" here) are corrupt. I'll symbolize them with "?" :
Code:
[--??--???-](--???-?-----------????-----------??-?--??--)
Now you figure the workaround don't you ? We need to move our /system & /data partitions to places that are clean, at the cost of reducing their sizes :
Code:
--??--???---???-?[-----------]????(-----------)??-?--??--
We will strive to give /system its original size, or something close to it, while we can sacrifice more of the /data partition.
Ok, enough theory, let's move on to practice.
Here, in parted, /system = FACTORYFS and /data = DATAFS
We are going to remove the /data partition first, so we have some space to work on.
Enter the following :
>>> P6810 <<<
Code:
(parted) rm 9
>>> P6800 <<<
Code:
(parted) rm 10
Now please refer to the output of (parted) print you had earlier, just scroll up a little in your terminal window. See those Start/End values ? Well check the end value of your DATAFS partition and remember it.
Here's an example for P6810 :
Code:
9 *START -->*1137MB 15.3GB*<-- END* 4163MB ext2 DATAFS
So now comes the boring part. We are going to try to make a new clean /data partition.
Seems easy but the problem is :
- if you try to make it too big, it'll get stuck and return an I/O error.
- if some blocks are corrupt between the start/end values you'll enter it will get stuck and return an I/O error.
In both cases you'll have to reboot recovery and re-enter this in your terminal :
Code:
# adb shell
# parted /dev/block/mmcblk0
So this is long and boring to find the right place and the right size. Don't be greedy on the size, as long as you get at least 150-200mb it's cool, you'll be able to expand that later.
First you're gonna try to put the original end value (15300 in the p6810 example up there) as the new end value. So for the same example, if you wanna try to make a 500mb /data partition, you're gonna use 14800 as start value and 15300 as end value.
Ok let's go (this is still an example for p6810, for the p6800 owners, use your own (parted) print results) :
Code:
(parted) mkpartfs primary ext2 14800 15300
It will output something like this :
Code:
writing per-group metadata : XX %
Here there are two options :
- You were lucky, it will complete up to 100% and return "(parted)", which case you just have to enter the following :
>>> P6810 <<<
Code:
name 9 DATAFS
>>> P6800 <<<
Code:
name 10 DATAFS
- You were not lucky, it got stuck before reaching 100%, which case you have to reboot your recovery, re-enter parted and try again with a smaller start/end gap, or reducing the end value, you got about 14gb of space to try to make your partition, so it's sure you can find somewhere to put your small partition, just requires some blind testing.
Just remember to try to put your /data partition quite close to the end (original end value), so you still have some space to find somewhere to put your /system partition.
So now we'll assume you managed to have mkpartfs complete till 100%
Type this to see your updated partition table :
Code:
(parted) print
Now we're going to repeat last step with the /system partition.
Issue this :
>>> P6810 <<<
Code:
rm 8
>>> P6800 <<<
Code:
rm 9
The /system partition is much more important than /data, so you want to try to have its size remaining the same (872mb).
At first, you can try to re-make the /system partition with the same start/end values. It's not likely to work but it's worth trying.
Here's an example on P6810:
(again, if you're on P6800, then use your own start/end values for the 9th partition (FACTORYFS), you get them by typing print in parted).
Code:
(parted) mkpartfs primary ext2 264 1137
Same thing here, if it doesn't complete, then reboot recovery, type :
Code:
$ adb shell
# parted/dev/block/mmcblk0
And repeat this step until you find somewhere it works : (where YYY - XXX = 872)
Code:
(parted) mkpartfs primary ext2 XXX YYY
Remember to limit your research between FACTORYFS original start value (264 for P6810) and the new DATAFS start value you made, so you keep the order of the partitions.
Once you found the right place (where "writing per-group metadata" completes till 100%), type this :
>>> P6810 <<<
Code:
name 8 FACTORYFS
>>> P6800 <<<
Code:
name 9 FACTORYFS
The hardest part is done, if you type this you should get a full table of partition, make sure no number is missing or disordered (1,2,3,4,etc...).
Code:
(parted) print
3) Meet another good friend : e2fsck
Now we've done our fresh and clean partitions, you must be thinking we're done, but we're not ^^
In fact the two partitions we made are using ext2 filesystem, but the /system partition's filesystem should be ext4 (like it was at the beginning).
There are two ways of converting an ext2 filesystem to ext4 that I know of :
- Simply formatting /system in cwm recovery will convert the filesystem to ext4. To do this, just head to "mounts & storages" and select "format /system".
If it gets stuck while formatting, reboot your recovery by pressing the power+volume-up buttons for about 15 seconds, and head to the next part, you have to do something before you can try to format it again.
- Or issuing this in terminal :
>>> P6810 <<<
Code:
# tune2fs –O dir_index,uninit_bg,has_journal /dev/block/mmcblk0p8
>>> P6800 <<<
Code:
# tune2fs –O dir_index,uninit_bg,has_journal /dev/block/mmcblk0p9
To make sure either of the two ways worked do this :
Code:
# parted /dev/block/mmcblk0
(parted) print
And look if FACTORYFS shows ext4.
If it does, reboot recovery, then on to next part. If it doesn't, then still reboot recovery and head to next part, after which I'll redirect you here to try again.
Now we are going to use e2fsck to check our new partitions for errors, but not only, it also fixes some erros and it will even for example create lost & found in /data
So let's go, we'll begin with /system. If you're still in the (parted) shell, use ctrl+c and type "adb shell", then issue the following :
>>> P6810 <<<
Code:
e2fsck -yfDC0 /dev/block/mmcblk0p8
>>> P6800 <<<
Code:
e2fsck -yfDC0 /dev/block/mmcblk0p9
This might take long, or not, this might get stuck, or not. Either way reboot recovery if it gets stuck or whatever, but do it again till it finishes properly.
This is what my /system e2fsck final output looks like (p6810) :
Code:
/dev/block/mmcblk0p8: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p8: 2636/53312 files (1.2% non-contiguous), 101948/212890 blocks
If you got 0.0% or like less than 5% in "(X.X% non-contiguous)" this is a good sign.
Now reboot recovery and let's do the same for /data :
>>> P6810 <<<
Code:
# e2fsck -yfDC0 /dev/block/mmcblk0p9
>>> P6800 <<<
Code:
# e2fsck -yfDC0 /dev/block/mmcblk0p10
Same thing here, if it gets stuck then reboot recovery and do it again.
Here you should get 0.0% non contiguous. If you don't, in cwm do wipe data/factory reset, then reboot recovery and do this e2fsck again.
Ok now you got both clean e2fsck, (if you still have an ext2 FACTORYFS then now is the time to go back to try converting ext2 to ext4 again)
Make sure the e2fsck still are clean by doing this (it should be quick this time) :
>>> P6810 <<<
Code:
# e2fsck -cy /dev/block/mmcblk0p8
# e2fsck -cy /dev/block/mmcblk0p9
>>> P6800 <<<
Code:
# e2fsck -cy /dev/block/mmcblk0p9
# e2fsck -cy /dev/block/mmcblk0p10
Now you should be nearly good to go ! :laugh:
Download the cm9/cm10-based rom you want, make sure you check known issues and that you like this rom because everytime you'll want to flash a rom it's likely you'll have to do the whole e2fsck part again, or even sometimes the whole guide.
Now reboot in recovery and flash the rom. Two options :
- it flashes, then reboot, pray and be patient, if it takes more than 15 minutes to boot first time, then reboot it again, do this a few times if it doesn't boot, it might eventually do. If it doesn't, then reboot recovery and redo the e2fsck command for both /data and /system, let it fix things if it has to, then reboot again. Anyway it should have booted by now.
- flashing gets stuck : make sure you waited at least 5 minutes then reboot recovery---> wipe data/factory reset---> wipe dalvik cache---> reboot recovery---> adb shell and redo the e2fsck on both /data and /system, then try flashing again.
DO NOT FLASH THE GAPPS NOW, that will screw all you just done ! If you need the gapps then head to the following section of this guide.
4) Installing the gapps
If you flash the gapps after flashing the rom you'll be screwed, you'll have to redo the e2fsck part and maybe even the parted, and I know you don't want to.
So the workaround is to add the gapps to the cm-based rom you downloaded.
It's easy, just follow me :
Open the zipped rom you downloaded with 7zip or WinRar (Windows), or with Archive Manager or else (Ubuntu). Do not extract it, we'll modify the zip directly.
Do the same with the gapps, so you have both archive side to side.
In the rom, you have boot.img, and two folders : "META-INF" and "system". We will modify things in "system" folder ONLY. Open "system" folder.
In the gapps we will only use things from the "system" and "optional" folders.
The rest is pretty easy to figure out. In the gapps's "system" and "optional" folders you have folders which have the same name as some folders in "system" of the rom.
Just copy/replace everything that is in those folders of the gapps to the corresponding folders of the rom. Don't forget to do that with both "system" AND "optional" folders of the gapps.
When it's done just close the freshly modified rom, copy it to your tab's external sdcard and flash it.
If you don't have an external sdcard, then reboot recovery, copy the rom to the "platform-tools" folder of your android-sdk and rename it rom.zip.
Then return to your terminal and do the following :
Code:
$ adb push rom.zip /sdcard
It will now be in your internal sdcard (remember you shrinked it earlier so make sure the rom doesn't take all the space).
5) Expanding your internal storage
I don't recommend you do this the first time you follow this guide.
It might screw your /data partition so you have to do the whole process I describe in this guide again.
Anyway if you wanna try, this allowed me to earn a few extra gigs (never managed to get back more than 4gb and boot).
Here's what to do :
>>> P6810 <<<
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) resize 9
>>> P6800 <<<
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) resize 10
This will output something like :
Code:
Start ?
End ?
writing per-group metadata : XX %
You can only move the end value in fact, trying to change the start value will return an error. Try doing this to earn like 250mb at a time so it doesn't get stuck. Good luck.
6) Extra cases
If when booting in recovery, the recovery says something like "can't read /cache/recovery/last-log, Read-Only file system" then your /cache partition is corrupt.
Then you'll need to recreate it with parted. /cache is quite small (209mb) so it should be easy to have "writing per-group metadata" finishing.
Here are the commands to remove and recreate /cache with parted (it's the same on both models) :
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) print
(parted) rm 7
(parted) mkpartfs primary ext2 XX YY (where YY - XX = 209 and YY < FACTORYFS start value)

Nice guide...dude. Thanks for sharing

i being running e2fsck -yfDC0 /dev/block/mmcblk0p10 on my p6800 since yesterday this time. till now still show error reading block *******<attempt to read block from filesystem resulted in short read> while getting next indoe from scan. ignore error? yes
force rewrite? yes
question now is should i let it keep running or change to e2fsck -fDC0 /dev/block/mmcblk0p10 ?? hmm

Josvaz said:
i being running e2fsck -yfDC0 /dev/block/mmcblk0p10 on my p6800 since yesterday this time. till now still show error reading block *******<attempt to read block from filesystem resulted in short read> while getting next indoe from scan. ignore error? yes
force rewrite? yes
question now is should i let it keep running or change to e2fsck -fDC0 /dev/block/mmcblk0p10 ?? hmm
Click to expand...
Click to collapse
Not sure but this "attempt to read block resulted in short-read" error remembers me of my own brick, I think it's the error you get when you can't mount /data in recovery's mounts & storages.
Try to mount /data and if recovery can't mount it, then u need to recreate your /data partition with parted, like it's explained in this guide.
e2fsck alone won't fix it if it's not mountable.
Just talking from my own experience, but there might be other ways.

two questions:
1) i read something about having to back up the /efs partition? as it contains your bluetooth mac id and your emei number before flashing any alternative pit file
2) when i try to start the android SDK installer it says "Java SE Development Kit (JDK) no found. </br> Error: Failed to find Java version for 'C:\Windows\system32\java.exe,' blah blah blah"--is it because i tried to install the jdk 64-bit?
---EDIT--- solved the installation problem. setting up android SDK now...

aletheus said:
two questions:
1) i read something about having to back up the /efs partition? as it contains your bluetooth mac id and your emei number before flashing any alternative pit file
2) when i try to start the android SDK installer it says "Java SE Development Kit (JDK) no found. </br> Error: Failed to find Java version for 'C:\Windows\system32\java.exe,' blah blah blah"--is it because i tried to install the jdk 64-bit?
---EDIT--- solved the installation problem. setting up android SDK now...
Click to expand...
Click to collapse
Well yeah you can backup your efs but if you follow exactly this guide there's no way you can mess up your efs, as it's the first partition and we only deal with partitons 8 to 10.
Not sure but this "attempt to read block resulted in short-read" error remembers me of my own brick, I think it's the error you get when you can't mount /data in recovery's mounts & storages.
Try to mount /data and if recovery can't mount it, then u need to recreate your /data partition with parted, like it's explained in this guide.
e2fsck alone won't fix it if it's not mountable.
Just talking from my own experience, but there might be other ways.
Click to expand...
Click to collapse
I guess e2fsck won't run if the partition you check isn't mountable.
But you're right that e2fsck can't fix everything, the method I describe is drastic but it works.
So Josvaz, if after running e2fsck - try any options you want, won't harm (but add -y so it answers yes to all and you can go have a coffee) - you see more than 2 or 3% in " XX.XX% non contiguous" then remove your partition and recreate it using parted's mkpartfs, and re-run e2fsck, it should now be clean (0.0% non contiguous) and you can flash on it and boot your tab if your /system is clean (or close to) too.
Good luck.

Androguide.fr said:
- The first is to flash a PIT file with ODIN that will repartition your tab for you.
I will not cover this method as hg42 already wrote a very detailed tutorial about this. This tutorial is about Galaxy Note but you can appIy it to our 7.7 and you'll find PITs for P6800 there. I will soon make pits for P6810 using the scripts provided in hg42's guide.
Click to expand...
Click to collapse
but if i use this method, do i need to back up the /efs partition? i guess, i need the experience with abd, and its certainly not going to hurt anything if i do, and didn't need to. so i'll try that and see if i get a response in the mean time.
hg42 said:
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
Click to expand...
Click to collapse
is this possibly a way to avoid having to go through this process every few days or so?

aletheus said:
but if i use this method, do i need to back up the /efs partition? i guess, i need the experience with abd, and its certainly not going to hurt anything if i do, and didn't need to. so i'll try that and see if i get a response in the mean time.
Click to expand...
Click to collapse
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.

giving up lol .. any thing i need to do before i send to samsung ? like original pit, rom etc? anyone have original pit file ?

Josvaz said:
giving up lol .. any thing i need to do before i send to samsung ? like original pit, rom etc? anyone have original pit file ?
Click to expand...
Click to collapse
Don't give up, follow the guide step by step, I assure you that you can get your tab finally booting if you do.

Androguide.fr said:
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.
Click to expand...
Click to collapse
okay, but i need adb to back up /efs i think.

aletheus said:
okay, but i need adb to back up /efs i think.
Click to expand...
Click to collapse
Good for you xda recognized developer lyriquidperfection made a tool to backup and restore your efs on samsung devices, head to this thread : http://forum.xda-developers.com/showthread.php?t=1308546

hee i wanna quit cos i cant save more than half the space, manage 3.82GB left~

Androguide.fr said:
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.
Click to expand...
Click to collapse
the efs back up, is that used from within adb, or flashed as part of a recovery or? in other words, how do i use it?

aletheus said:
the efs back up, is that used from within adb, or flashed as part of a recovery or? in other words, how do i use it?
Click to expand...
Click to collapse
It's not done from adb, some apps allow you to backup/restore it (eg : Voodoo Sim Unlock for sgs3), check out the thread I linked earlier.

The best advice I can give to people who haven't bricked their tab (already?^^) : DO NOT EVER WIPE ANYTHING WHILE RUNNING STOCK 7.7 ROMS
Click to expand...
Click to collapse
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol

sos_sifou said:
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol
Click to expand...
Click to collapse
Yeah whether hc or ics, for some reason, samsung devs thought it was a good idea to include mmc_cap erase a.k.a superbrick bug in their kernels.
Anyway I doubt you'd love to stay on y
touchwiz hc, which the most laggy experience I ever had.

sos_sifou said:
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol
Click to expand...
Click to collapse
it wont be a problem in honeycomb...
but its a big problem in ICS

Anyway I doubt you'd love to stay on y
touchwiz hc, which the most laggy experience I ever had.
Click to expand...
Click to collapse
yeah I don't think that i will keep using hc for long, but consider that most isc roms are pipi-caca (wifi issues and battery drain) Ill wait for some stable builds (just like overcome on my beloved "sold" GTP1000).
I think that dedraks made a new kernel which is without the brick bug ? is it safe to use with hc ??
and thanks for the great work you're doing on the new galaxy tab 7.7 (merci beaucoup !)

so i have not figured out how to get a working pit file flashed. there are so many, and i VAGUELY understand his numbering system, so i figured i'd start with the smallest available space first, because that one would be the most likely to account for any bad blocks. i tried nearly ALL of them. now i'm trying to test to see whether adb is able to access ANYTHING-- (tab is booting into recovery and download, and adb detects the device from windows) however, what i'm getting is "/sbin/sh: parted: not found" is that saying that parted cant be found or that parted cant find the reference block? researching this now.
so obviously, i've had to sit down and warm up to your NOOB GUIDE!!! its very clear, i just havent done this level of anything with android, tho what better way to learn than sink or swim? problem is, i'm an artist, and pretty broke.... my computer fried months and months ago, and i just decided i'd rather spend my extra cash on the gTab 7.7 cus is the largest affordable sAMOLED to date, and well, a 30% expansion of the standard color model really appealed to me, so the only thing i have to work on is my super bricked tab!!! a friend of mine is lending me her laptop while she's at work, and i'd like to try to fix it this evening.... ughh....
if anybody can help me figure out my way through this tutorial, i'll be researching why 'parted' isn't working.
THANKS!!!
---UPDATE
okay, so for some reason, i can't seem to push files from adb to the device. from what i've read, i have to manually install parted to sbin, (or there's a flashable kit available also) but i can't figure out how to get it to pick up the file (its in the folder with ADB.exe, so i shouldn't need to reference the path for the copy location, right?)
now i'm looking up general "ADB device navigation and testing"
---ugghhh....

[HOW-TO] Convert to F2FS on Nexus 6 (Any Rom)

I didn't see anything about how to convert to f2fs for the nexus 6 so I thought i'd write something up as somebody requested me to do this.
What are the benefits of using f2fs over ext4?
I could list pros and cons, but I strongly encourage you to do your own research on the matter.
Should I do this
If you want to at your own risk
Pre-requisites
You need a recovery that supports f2fs in kernel and has the f2fs tools. Dhacker20 has provided one (TWRP 2.8.5.0) here: https://twitter.com/dhacker29/status/568070387306766336
You will need a kernel that supports f2fs for /cache and /data (Obviously I recommend Zen Kernel, but there are some others. Zen has the newest f2fs from upstream, while others may not)
ONLY YOU ARE RESPONSIBLE FOR YOUR DATA. IT IS YOUR RESPONSIBILITY TO UNDERSTAND THE RISKS AND YOUR RESPONSIBILITY TO BACKUP YOUR DATA
How-To
1.) Back up everything you care about to your PC (everything will be erased, including sdcard)
2.) Install a kernel that supports f2fs. Get the boot.img and do "fastboot flash boot boot.img" in bootloader (Like Zen)
3.) Install the recovery with f2fs support (fastboot flash recovery twrp-recvery-f2fs.img)
4.) In TWRP, go to Wipe
5.) Do a full wipe by swiping right
6.) Go to Wipe -> Advanced Wipe
7.) Choose /cache
8.) Choose "Change Filesystem"
9.) Pick f2fs, proceed
10.) Do the same thing for /data
11.) While still in recovery, plug phone into PC and do this:
Code:
# adb shell
# mount -o rw /system
# cp /sbin/fsck.f2fs /system/bin/
# cp /sbin/mkfs.f2fs /system/bin/
# chmod a+x /system/bin/*f2fs*
12.) Reboot and you are done.

Reserved

Is adb shell in terminal app

jiv101 said:
Is adb shell in terminal app
Click to expand...
Click to collapse
No adb is part of the android SDK platform-tools

I did this a while ago (except for step 12), and I remember something happening, which caused my data partition to become corrupted. I tried to format the partition again using ext3 or whatever the default is and that ended up giving me a soft brick. I had to restore the factory software. I have read things of where it does improve R/W speeds but I don't know if it's worth the hassle of possibly losing everything at the drop of a hat if you flash ROMs often.

RSVP..
Thanks for the information on F2FS well needed..!

brando56894 said:
I did this a while ago (except for step 12), and I remember something happening, which caused my data partition to become corrupted. I tried to format the partition again using ext3 or whatever the default is and that ended up giving me a soft brick. I had to restore the factory software. I have read things of where it does improve R/W speeds but I don't know if it's worth the hassle of possibly losing everything at the drop of a hat if you flash ROMs often.
Click to expand...
Click to collapse
The last step is a huge component of the whole process. If the rom doesn't have f2fs-tools in by default (most don't have fsck.f2fs/mkfs.f2fs) you will not have standard integrity checking every time you boot like you do on ext4. If you do the last step you will get integrity checking every time you bootup.
Also, since f2fs is a relatively young file system it can do harm to revert to older versions of the file system. For example, zen kernel has the newest f2fs which was updated last about 2 days ago. If you go on stock kernel you will find an f2fs that is 1+ year old. There may be a compatibility issue between these two where if you flash different roms (which almost always bundle a kernel)/kernels you will almost certainly have an issue.
But that's all part of the risk with using a relatively young file system. I do not understate the risks of data corruption in doing something like this - but anybody who is doing this and has significant worry should take precautions is backing up all their important files.

bbedward said:
The last step is a huge component of the whole process. If the rom doesn't have f2fs-tools in by default (most don't have fsck.f2fs/mkfs.f2fs) you will not have standard integrity checking every time you boot like you do on ext4. If you do the last step you will get integrity checking every time you bootup.
Also, since f2fs is a relatively young file system it can do harm to revert to older versions of the file system. For example, zen kernel has the newest f2fs which was updated last about 2 days ago. If you go on stock kernel you will find an f2fs that is 1+ year old. There may be a compatibility issue between these two where if you flash different roms (which almost always bundle a kernel)/kernels you will almost certainly have an issue.
But that's all part of the risk with using a relatively young file system. I do not understate the risks of data corruption in doing something like this - but anybody who is doing this and has significant worry should take precautions is backing up all their important files.
Click to expand...
Click to collapse
Is there any sort of confirmations when you are doing the last steps? I see this when I do them and I'm not sure if it has actually done the last steps.
C:\Development\platform-tools>adb shell
~ # ←[6nmount -o rw /system
mount -o rw /system
~ # ←[6ncp /sbin/fsck.f2fs /system/bin/
cp /sbin/fsck.f2fs /system/bin/
~ # ←[6ncp /sbin/mkfs.f2fs /system/bin/
cp /sbin/mkfs.f2fs /system/bin/
~ # ←[6nchmod a+x /system/bin/*f2fs*
chmod a+x /system/bin/*f2fs*
~ # ←[6n
C:\Development\platform-tools>

lobrau said:
Is there any sort of confirmations when you are doing the last steps? I see this when I do them and I'm not sure if it has actually done the last steps.
C:\Development\platform-tools>adb shell
~ # ←[6nmount -o rw /system
mount -o rw /system
~ # ←[6ncp /sbin/fsck.f2fs /system/bin/
cp /sbin/fsck.f2fs /system/bin/
~ # ←[6ncp /sbin/mkfs.f2fs /system/bin/
cp /sbin/mkfs.f2fs /system/bin/
~ # ←[6nchmod a+x /system/bin/*f2fs*
chmod a+x /system/bin/*f2fs*
~ # ←[6n
C:\Development\platform-tools>
Click to expand...
Click to collapse
That's about it, you can type exit to get out of adb shell or just close it.
On your device you can make sure f2fs took by simply typing "mount" in terminal emulator. You should see you data and cache reads f2fs now.

lobrau said:
Is there any sort of confirmations when you are doing the last steps? I see this when I do them and I'm not sure if it has actually done the last steps.
C:\Development\platform-tools>adb shell
~ # ←[6nmount -o rw /system
mount -o rw /system
~ # ←[6ncp /sbin/fsck.f2fs /system/bin/
cp /sbin/fsck.f2fs /system/bin/
~ # ←[6ncp /sbin/mkfs.f2fs /system/bin/
cp /sbin/mkfs.f2fs /system/bin/
~ # ←[6nchmod a+x /system/bin/*f2fs*
chmod a+x /system/bin/*f2fs*
~ # ←[6n
C:\Development\platform-tools>
Click to expand...
Click to collapse
Nope, it will only inform you if something went wrong (like file not found) of it all went through with no error it worked.
After you bootup you can verify it worked by typing "mount" in adb shell or terminal emulator. It should say f2fs on /data and /cache. Also in something like root Explorer if you navigate to /system/bin you should see the files you copied (fsck.f2fs and mkfs.f2fs)

bbedward said:
Nope, it will only inform you if something went wrong (like file not found) of it all went through with no error it worked.
After you bootup you can verify it worked by typing "mount" in adb shell or terminal emulator. It should say f2fs on /data and /cache. Also in something like root Explorer if you navigate to /system/bin you should see the files you copied (fsck.f2fs and mkfs.f2fs)
Click to expand...
Click to collapse
Perfect thanks for the quick response looked like it worked. Just out of curiosity is there any reason to format system to f2fs or does it end up causing issues, or just no changes in use?

lobrau said:
Perfect thanks for the quick response looked like it worked. Just out of curiosity is there any reason to format system to f2fs or does it end up causing issues, or just no changes in use?
Click to expand...
Click to collapse
I've tested it partly in testing the newest f2fs Zen merges as well as just general f2fs testing before.
It seems like writes are a bit faster, especially sql stuff. I've seen some grossly huge benchmark differences on other devices - on the n6 I've seen improvements but nothing astronomical like those benchmarks portrayed (I presume the 200% increase in write performance they showed is not accurate regardless) .

Recovery
So currently I'm on a 5.1 stock based rom (sinless) and TWRP 2.8.6
HAve Downloaded the latest Zen Kernel, and am downloading the latest 5.1 Benzo Rom.
Am I going to have issues rolling back to a 2.8.5 recovery - does 2.8.5 support 5.1 based roms?

shaitan667 said:
So currently I'm on a 5.1 stock based rom (sinless) and TWRP 2.8.6
HAve Downloaded the latest Zen Kernel, and am downloading the latest 5.1 Benzo Rom.
Am I going to have issues rolling back to a 2.8.5 recovery - does 2.8.5 support 5.1 based roms?
Click to expand...
Click to collapse
Yea it's compatible. There isn't a 2.8.6 with f2fs support yet that I know if and I haven't had the time to make one myself, but the 2.8.5 one works just fine.

@bbedward
I didn’t know any about the part 11 (I mean I convert mine to F2FS before I read this) so I’m wondering I’m gonna face any problem or not?
And also if have to do it, can I do it now or I have to wipe everything and then do it (cause changing partition to F2FS will clean everything)
Also I’m on your kernel.

dany20mh said:
@bbedward
I didn’t know any about the part 11 (I mean I convert mine to F2FS before I read this) so I’m wondering I’m gonna face any problem or not?
And also if have to do it, can I do it now or I have to wipe everything and then do it (cause changing partition to F2FS will clean everything)
Also I’m on your kernel.
Click to expand...
Click to collapse
Every time you boot your phone, it automatically runs fsck (for ext4 on stock). Essentially it's an automatic integrity check and repair.
So if it finds issues at boot up in the file system, it will tend to fix them automatically. If you look at boot up logs currently you will probably see something like "/system/bin/fsck.f2fs not found skipping integrity check"
You don't have to wipe everything though, you can just install the tools now.
I'm almost happy I posted this now hopefully it saves a few filesystems for folks who didn't do it completely.
---
When you see a kernel say f2fs compatible it means:
- f2fs is built into the kernel or a module is provided
- It's ramdisk's fstab allows for mounting of partitions as f2fs. On zen - it supports /data and /cache
When you see a rom say f2fs compatible it means:
- They have an f2fs-compatible kernel included
- They have the f2fs tools in the rom (As step 11 does)
This is why I say in the title this is "Any Rom" compatible as it will work on any rom, while on other devices you may see "Rom x, rom y, and rom z are the only known roms to be fully compatible." If you just do it this way it doesn't matter because it'll make any rom compatible with f2fs.

@bbedward this worked perfectly! But I just want to confirm that it switches back to ext4 after flashing a new ROM? After wiping and doing a clean flash it seems I'm not booting in f2fs anymore.
Am I doing something wrong or will I have to do this every time I clean flash?
Thanks again for the tutorial!

philsfan said:
@bbedward this worked perfectly! But I just want to confirm that it switches back to ext4 after flashing a new ROM? After wiping and doing a clean flash it seems I'm not booting in f2fs anymore.
Am I doing something wrong or will I have to do this every time I clean flash?
Thanks again for the tutorial!
Click to expand...
Click to collapse
I think most likely when you flashed a rom it overwrote your f2fs kernel, which caused it to reformat to ext4 when you booted it up.
Whenever you flash a rom you will need to flash f2fs-kernel right afterwards, and re-copy the tools (step 11) if the rom doesnt have them already in order to keep f2fs.

bbedward said:
I think most likely when you flashed a rom it overwrote your f2fs kernel, which caused it to reformat to ext4 when you booted it up.
Whenever you flash a rom you will need to flash f2fs-kernel right afterwards, and re-copy the tools (step 11) if the rom doesnt have them already in order to keep f2fs.
Click to expand...
Click to collapse
Thanks for responding so soon!
So I did flash zen9 (so good BTW) immediately after but I didn't repeat step 11 again. So that means Chroma doesn't have the necessary files for f2fs, good to know!
Edit: @bbedward does that mean I don't have to reformat again? Just do step 11?
Edit 2: entered step 11 in recovery and now i'm back to f2fs thanks again!

bbedward said:
The last step is a huge component of the whole process. If the rom doesn't have f2fs-tools in by default (most don't have fsck.f2fs/mkfs.f2fs) you will not have standard integrity checking every time you boot like you do on ext4. If you do the last step you will get integrity checking every time you bootup.
Also, since f2fs is a relatively young file system it can do harm to revert to older versions of the file system. For example, zen kernel has the newest f2fs which was updated last about 2 days ago. If you go on stock kernel you will find an f2fs that is 1+ year old. There may be a compatibility issue between these two where if you flash different roms (which almost always bundle a kernel)/kernels you will almost certainly have an issue.
But that's all part of the risk with using a relatively young file system. I do not understate the risks of data corruption in doing something like this - but anybody who is doing this and has significant worry should take precautions is backing up all their important files.
Click to expand...
Click to collapse
That was probably it! It was just a pain because this is the first phone that I've had in a while that doesn't have an SD card, I had a nandroid, but it doesn't do any good if you can't access your data partition Hahaha I have now taken to uploading my nandroids to Google Drive or putting them on my pc just in case that happens.