Some possible insight on the cause of the RFS lag and work-around

Search This thread

bilboa1

Inactive Recognized Developer
Aug 16, 2010
1,291
683
Since I installed JPK on a test phone after claims that the RFS related lag has been fixed.. well.. I'd like to share my impressions:

- I have installed approx 100 apps after the flash (flashed / wiped / factory reset btw)

A this point, the phone while slightly slower than one with Voodoo is pretty fast

A few days later, it's still good enough.

- 5 days later, lag starts to be felt, and it's stronger every next day until it becomes annoying to use


That's exactly the same experience as I had on various Eclair roms without any lag-fix. I also had this on JP3 (early Froyo).

So yeah. I looked into the /init binary from samsung and it's supposed to make some file system checks from time to time when you restart the phone, but it does not appear to really carry on with that.

So I ran the checks myself:

- you need a rooted phone, and adb or a terminal

- find all RFS partitions:
$ su
# mount|grep -i rfs

- kill all processes, go flight mode and remount them read-only
$ su (if you're not root.. not going to repeat it again for subsequent commands)
# kill -9 <pid> of anything that use the patrition
# mount -oremount,ro /dev/block/....

- check the RFS filesystem and correct errors
# /system/bin/fsck_msdos -p -f /dev/block/....

Surprise, a million of RFS errors fixed such as:

/path/to/file starts with free cluster FIXED
Cluster XXX continues with cluster XXX in FAT 0 but is marked free in FAT 1 FIXED
Detected cluster chain loop head XXXX for p XXXX FIXED
FSNext block XXX is correct NumClusters XXX FIXED (weird one)
No LOST.DIR FIXED
Lost cluster chain at cluster XXX YY clusters lost FIXED (prolly lost files/data here!)

Repeat for each partition

reboot the phone at the end

SURPRISE! It doesn't lag much anymore.

Use the phone an hour, do the check again and you will see it's already full of errors.

Conclusion:

RFS is bugged (we knew that didn't we) but it looks like it's fixable, if ever Samsung figures out what is corrupting the file system exactly (it's closed source so we can't really find out easily)

It might be possible to figure it out by looking at VFAT sources too.


I would be very interested to see if that fixes the lag for everyone or if i'm an isolated case and all my RFS partitions are on bad hardware or if it's really software corruption as I am guessing


Small disclaimer:
im not responsible for any data loss etc. no warranties etc. fixing file system even readonly might cause data loss due to the bugs in RFS. you've been warned lol.
 
Last edited:

RyanZA

Senior Member
Jan 21, 2006
2,023
784
JHB
Since I installed JPK on a test phone after claims that the RFS related lag has been fixed.. well.. I'd like to share my impressions:

- I have installed approx 100 apps after the flash (flashed / wiped / factory reset btw)

A this point, the phone while slightly slower than one with Voodoo is pretty fast

A few days later, it's still good enough.

- 5 days later, lag starts to be felt, and it's stronger every next day until it becomes annoying to use


That's exactly the same experience as I had on various Eclair roms without any lag-fix. I also had this on JP3 (early Froyo).

So yeah. I looked into the /init binary from samsung and it's supposed to make some file system checks from time to time when you restart the phone, but it does not appear to really carry on with that.

So I ran the checks myself:

- you need a rooted phone, and adb or a terminal

- find all RFS partitions:
$ su
# mount|grep -i rfs

- kill all processes, go flight mode and remount them read-only
$ su (if you're not root.. not going to repeat it again for subsequent commands)
# kill -9 <pid> of anything that use the patrition
# mount -oremount,ro /dev/block/....

- check the RFS filesystem and correct errors
# /system/bin/fsck_msdos -p -f /dev/block/....

Surprise, a million of RFS errors fixed such as:

/path/to/file starts with free cluster FIXED
Cluster XXX continues with cluster XXX in FAT 0 but is marked free in FAT 1 FIXED
Detected cluster chain loop head XXXX for p XXXX FIXED
FSNext block XXX is correct NumClusters XXX FIXED (weird one)
No LOST.DIR FIXED
Lost cluster chain at cluster XXX YY clusters lost FIXED (prolly lost files/data here!)

Repeat for each partition

reboot the phone at the end

SURPRISE! It doesn't lag much anymore.

Use the phone an hour, do the check again and you will see it's already full of errors.

Conclusion:

RFS is bugged (we knew that didn't we) but it looks like it's fixable, if ever Samsung figures out what is corrupting the file system exactly (it's closed source so we can't really find out easily)

It might be possible to figure it out by looking at VFAT sources too.


I would be very interested to see if that fixes the lag for everyone or if i'm an isolated case and all my RFS partitions are on bad hardware or if it's really software corruption as I am guessing


Small disclaimer:
im not responsible for any data loss etc. no warranties etc. fixing file system even readonly might cause data loss due to the bugs in RFS. you've been warned lol.

VOLD is what does the RFS check at boot. It seems to run, although maybe it fails? It definitely does run though, you can check it running using 'ps' on phone boot. Maybe it's only cleaning up /sdcard though.

At any rate, running the disk check does help with speed, but it doesn't help that much. It's still slow. I think if you want to stick with RFS, you need to do a defrag as well as the filesystem check. After some use, RFS must be very very fragemented on most people's phones.

Even in perfect condition though, RFS still has some very nasty properties such as locking the entire disk when a write occurs, not doing buffering, etc etc.
 

RyanZA

Senior Member
Jan 21, 2006
2,023
784
JHB
Could someone just create an app that does this?

An app can't do this, since the app would have to be running off RFS and would crash/have to be killed to perform the FS checks. It could be done on boot using some trickery and the playlogos / replace binary trick. Or it can be done by replacing the init script with some kernel hackery. But at that point, you might as well just use a real filesystem. ;)

I guess a PC .bat file could be made that uses adb to do this for you and then reboot the phone... Doesn't seem worth the trouble though!
 

dakine

Senior Member
Nov 13, 2006
748
34
Nice job figuring this out. Is someone forwarding all these findings to that Samsung dev?
 

bilboa1

Inactive Recognized Developer
Aug 16, 2010
1,291
683
It's not about RFS vs the other filesystems. I'm well aware of the performance of RFS. But it's decent enough when it's working properly. It's not nearly as fast as ext but fast enough that you don't get annoyed.

Thus fixing RFS would make the life of many people who aren't technically inclined better. If the RFS do get all corrupted everywhere, and Samsung figure that out and fixes it, it means a good thing for most people.

The rest of us will end up on ext anyways

And yeah I think the fscheck at boot fails, it must fail actually, i don't see how else it would happen.
 

RyanZA

Senior Member
Jan 21, 2006
2,023
784
JHB
It's not about RFS vs the other filesystems. I'm well aware of the performance of RFS. But it's decent enough when it's working properly. It's not nearly as fast as ext but fast enough that you don't get annoyed.

Thus fixing RFS would make the life of many people who aren't technically inclined better. If the RFS do get all corrupted everywhere, and Samsung figure that out and fixes it, it means a good thing for most people.

The rest of us will end up on ext anyways

And yeah I think the fscheck at boot fails, it must fail actually, i don't see how else it would happen.

What firmware did you test on, btw? I've noticed that JPK does seem to take longer on the FS checks, so maybe they have it fixed already (doubt it though)?
 

hardcore

Senior Member
Sep 12, 2006
3,435
7,992
VOLD is what does the RFS check at boot. It seems to run, although maybe it fails? It definitely does run though, you can check it running using 'ps' on phone boot. Maybe it's only cleaning up /sdcard though.
I think VOLD only does the checks for the Internal SD and External SD, not the RFS partitions.

Interesting find though, about the FS errors.
 

sargasso

Senior Member
Sep 7, 2010
174
22
I’ve been wondering why the lag appears after a couple of days. I suspected corruption in one way or another myself, as it stays after a reboot it could not have been RAM and there are no signs of running out of space. Thanks for your research and I hope it will lead to new fixes. Sad but true my fix is to reflash my phone almost weekly.

I run Doc's JPK super slim ROM which is really nice but still it lags, even with OCLF installed.

Yesterday I take my phone out of my pocket to take a quick photo. My phone wakes up and I sweep the glass. Halfway through the sweeping the animation stops. I wait patiently for a second or three and there my home screen is. (No widgets, no animations, just a single home screen with 12 icons on it of the applications I actually use). I click on the camera icon and I wait another 5 seconds for the camera to realize it is not supposed to sleep on duty. I make a photo, the actual moment is already gone by now but hey I have the thing in my hand. It just takes another 5 seconds to store the photo.

It is like being in a hurry with a toddler with you. You want to go quicker but you can’t get angry cause the little thing just can’t go faster. It has to stop and wonder about life every once in a while.

I like my phone and I am sure it will grow up.
 

dakine

Senior Member
Nov 13, 2006
748
34
Maybe move this to the development forum then it might get more traffic from people that can actually help.
 

RyanZA

Senior Member
Jan 21, 2006
2,023
784
JHB
Some further info on possible RFS fixes here:

http://xdaforums.com/showpost.php?p=8445244&postcount=143

With the sync issue fixed, and corruption fixed with checks, RFS might just work 'okay'! It won't be as fast as EXT, but it should still work fine if we can sort out all the bugs! And we have a much better chance of getting Samsung to include these fixes in a new firmware too.

If we could get hold of Samsung somehow, and manage to convince them that they should

1) disable the always sync behaviour
2) do full filesystem checks at boot up (or provide a utility to do the checks)

then RFS should be A LOT more usable! :D
 

bilboa1

Inactive Recognized Developer
Aug 16, 2010
1,291
683
Some further info on possible RFS fixes here:

http://xdaforums.com/showpost.php?p=8445244&postcount=143

With the sync issue fixed, and corruption fixed with checks, RFS might just work 'okay'! It won't be as fast as EXT, but it should still work fine if we can sort out all the bugs! And we have a much better chance of getting Samsung to include these fixes in a new firmware too.

If we could get hold of Samsung somehow, and manage to convince them that they should

1) disable the always sync behaviour
2) do full filesystem checks at boot up (or provide a utility to do the checks)

then RFS should be A LOT more usable! :D
That quite right, I noticed the sync issue also.
As for the corruption, 2 things should be fixed:
- fsck from init should actually fsck the partitions properly on boot (we can sort of fix that by calling it in a script again)
- corruption should in theory not even happen so Samsung would have to work on RFS for that one :p


I ran JM8 for 2 days now and my rfs partitions are full of errors, like in JPK, just for confirmation if there needed to be one.
In fact it's still running fsck on /system as I'm writting and issues are filling the terminal .. its been running for 30s already lol :(
 

bilboa1

Inactive Recognized Developer
Aug 16, 2010
1,291
683
Could someone perhaps turn this into a .bat-file?

I haven't tried that but it might be easier to enable adb over usb (in development settings) then .. make sure you are rooted, type that:
> adb shell
$ su
#
<prompt on the phone for root, click allow>
reboot into recovery

> adb shell
$ su
# mount -oremount,ro /dev/block/stl9
# mount -oremount,ro /dev/block/stl10
# mount -oremount,ro /dev/block/stl11
<for safety i'm not including stl3 it's the EFS)

if there's any error due to "filesystem busy" them stop there, it means it doesn't work :p
otherwise:

#/system/bin/fsck_msdos -p -f /dev/block/stl9
#/system/bin/fsck_msdos -p -f /dev/block/stl10
#/system/bin/fsck_msdos -p -f /dev/block/stl11
# reboot