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

I did the check for /cache and /system (stl9 and stl11) few days ago. My phone was starting to be very slow before doing this and surprisingly it seems to have helped. Could be also the reboot too but I did reboots earlier and I don't think I got this big difference.

JM7 rooted no lag-fix installed.

I hate to disappoint but it seems that running the fsck causes more problems that what it's worth. I don't know how RFS corrupts and IF it even corrupts. Who knows maybe the fsck is fixing things that don't even need fixing.

I definitely notice a speed improvement after fixing the errors BUT this is now the second time that something was broken after I ran it. First time happened two days ago and the home screen lost some widgets. I added them back and didn't think much of it. Today Folder organizer lost it's database after the fsck and I had to restore from backup.

Too bad I'm on Froyo or I'd be running Voodoo anyway. Can't wait to get rid of this RFS crap. Someone at Samsung should be shot for this mess!

EDIT: It seems Autokiller also got deleted.....and possibly more. The log from the fsck shows errors on these files. Needless to say they were working all very well before!

i noticed this as well. i ended up reflashing because i had constant issues with the native ext2 lagfix after running fsck, even after wiping and restoring previous backups. after reflashing it started working again and i am hesitant to use fsck-msdos again. there are errors with every sector saying fat 0 doesnt match fat 1 so something must be off.

ekhm, afair rfs is fat based, but running fsck_msdos which was developed for fat?!
are u guys sure that it is even compatible? running it might just try to “fix“ it back to fat..


Sent from my GT-I9000 using XDA App

Exactly Redf.. We simply don't have enough information here to know for sure..

If RFS was being corrupted that easily, wouldn't most phones be corrupting themselves? We haven't really seen any evidence of this happening.

Someone also noted that the filesystem apparently isn't checked on startup, so maybe it's a possibility that fsck is buggy/incomplete too.

andrewluecke said:

Exactly Redf.. We simply don't have enough information here to know for sure..

If RFS was being corrupted that easily, wouldn't most phones be corrupting themselves? We haven't really seen any evidence of this happening.

Someone also noted that the filesystem apparently isn't checked on startup, so maybe it's a possibility that fsck is buggy/incomplete too.

Click to expand...

Click to collapse

More than likely RFS stores additional metadata (for journaling, etc) that isn't part of the FAT32 spec. When using a FAT32 check disk that doesn't understand RFS metadata, it may just rampage right through it with an axe, causing corruption. The speed increase you see after doing a FAT32 disk check may be simply the result of the RFS journaling data being cleared, which means that the driver doesn't have to parse it. Who knows!

RyanZA said:

The speed increase you see after doing a FAT32 disk check may be simply the result of the RFS journaling data being cleared, which means that the driver doesn't have to parse it. Who knows!

Click to expand...

Click to collapse

Hey Ryanza in principle I agree. It seems like rfs is not killing data so something isn't understood, including the "fix". However, shouldn't the journal always get cleared on bootup? Isn't that the whole point of a journal.. that at bootup it's used to fix failed writes and then can be zero'd out? The journal corrections should not become permanently part of the files. In fact for example you can delete an ext3 journal on a clean drive and you just get an ext2 filesystem. Am I wrong?

edit: PS I'm not saying you're wrong or it's that simple, but that the journal should not be slowly building up making rfs slowly slower, if it's working in a reasonable way.

appagom said:

Hey Ryanza in principle I agree. It seems like rfs is not killing data so something isn't understood, including the "fix". However, shouldn't the journal always get cleared on bootup? Isn't that the whole point of a journal.. that at bootup it's used to fix failed writes and then can be zero'd out? The journal corrections should not become permanently part of the files. In fact for example you can delete an ext3 journal on a clean drive and you just get an ext2 filesystem. Am I wrong?

edit: PS I'm not saying you're wrong or it's that simple, but that the journal should not be slowly building up making rfs slowly slower, if it's working in a reasonable way.

Click to expand...

Click to collapse

Nope.. because of how FAT works, you can't easily add things like symlinks and permissions. So for every file you have, RFS creates a hidden metadata file. It puts the journal, link, permissions and everything else in here. It doesn't appear to get cleared, ever (but I don't know enough to guarantee this). The whole method used for metadata in RFS is going to be slow because of the parsing required.

Doing a FAT32 disk check sometimes seems to wipe out these metadata files, which is what causes the problems (files lose their permissions and so on).

So basically, RFS DOES definitely require some type of disk check to be run. Unfortunately, FAT32 disk check doesn't appear to be compatible.

To sum up, RFS is bad.

Hmm
Can't we do a program that clean that meta data? ??



Sent from my GT-I9000 using XDA App