yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 General] Guiper:
Just a small remark based on the test results posted here.

galaxy	/data	111.16s	111.54s	113.64s
galaxy	/sdcard	064.88s	064.15s	066.87s

As far as I understood /data and /sdcard are the same device, the 8 or 16GB MoviNAND, either mounted as RFS or FAT32 directly.

Can someone try to explain why plain FAT32 is 50% faster than RFS? The sync on close reason does not seem right, since probably the test was run using dd to create a single file. Can it be the journalling making 50% difference? The corruption?/fragmentation of the RFS partition? (can we run again the test of /data after checking (fsck) it?)

Any thoughts on it??

Regarding the discussion on EXT2 vs EXT4, my opinion is even if EXT2 is let's suppose 20% faster (which I really doubt, since it's a technology with 17 years!) I prefer the extra safety of ext4 if my device crashes or fall down to the ground.

Finally I don't thing the CPU overhead of the EXT4 filesystem are even notable to a CPU like we have on Galaxy S.

If I would bet to the fast filesystem, I would go for sure to the EXT4 without journalling, I like to think that the technology introduced and developed in the last 17 years overcomes the CPU overhead difference.

This is my 2 cents, unfortunately I don't have time to test or help actively in development.
[Galaxy S I9000 General] RyanZA:
Data safety aside (and data safety is important), comparing the speed of EXT2 vs non-journaled EXT4 seems to have EXT2 ahead. I don't really understand why, yet! I assumed CPU overhead, but it may also be simply bad testing, or something else. At any rate, the performance difference between non-journaled EXT4 and EX2 is likely to be too small to worry about, and it's more of a straw man than anything. The real discussion is EXT+journal or EXT+no journal. Theoretically EXT+journal should be safer, and almost definitely is safer. In practice, I haven't been able to make any tests that cause EXT2 to lose more data than EXT4, but again, it's probably just my tests that are badly done. :)

I don't really think that you can go horribly wrong with any form of EXT though, and probably straight FAT32+disk checks might be fine too, I haven't tested. RFS definitely seems to have something very strange going on though, beyond the sync on close or any FAT32 related issues. Perhaps it writes out a journal multiple times, or includes the actual data in the journal? Makes a back up of old data on each write? It's doing something!
[Galaxy S I9000 General] DamianGto:
RyanZA: well i think you start to looking at the right way.

Like i see it all filesystem can be used and be fast. The problem is what Samsung doing with this filsystem. That would be focus on, not witch filsystem is the best.

If you find that you would have solve the lag issue. Then all can use the information and use the filsystem they want. What they use should be there own likings.

//Damian
[Galaxy S I9000 General] spandsbab:
Very nice thread indeed...

I have read this thread and I'm happy to see a lot of useful info being exchanged and the fact that my nose bleeding finally stopped:D

I am looking forwards Supercurio's post (I hope his temper finally settles down; if not I hope he has seen Bruce Banner's breathing technique:p)...

Thanks To RyanZA's patience, I am not (by far) knowledgeable in this matter and my post in this thread is virtually useless but it's just to show support to devs who are giving their time to help make our SGS better than it is now:D
[Galaxy S I9000 General] K4P1:
Lag is fixed. Long live the fix!

Wondering what is actual cause of the lag when using RFS filesystem in SGS.

It could be something like not fully designed filesystem (still under developement?), problems or even some sort of incompatability with MoviNAND, delays when re-checking data to ensure it's flushed/fsynced correctly to card and then checked it, - who knows (Samsung developers? :confused: )

Just hoping that they are fine-tuning/re-designing or what ever to speed up file system's operations regardless if it is because of fflush/fsynced or other function(s) or even the whole disk operations logical design.

We all agree that SGS disk performance is really poor. Therefore it is good that some of us (RyanZA and supercurio - yes, both) have figured a way removing the annoying lag.

But why are you "fighting" about "I know this is the best/only real solution and the other's solution is some b***s**t"?

Both of your solutions works. Speed is allmost same. Every filesystem or fs over other fs can lead (and will lead) to data loss after (long) time.

Where is the problem?

After all - do we know 100% of all SGS hardware/software (eclair or froyo (soon) )?

IMHO you should work together or at least share your knowledge/problems/solutions to get safest/fastest/user selectable solution to the real problem.

Then user could select best method whatever user thinks is the best.

Just a suggestion ;)
[Galaxy S I9000 General] RyanZA:
I think there might be a bit of confusion regarding what I think of supercurio's Voodoo lagfix. I have zero problems with it, and I think it's awesome! I have no problems at all recommending it to everyone. The loopback EXT2 is far from the best/only solution. It works well and is easy to install, but that doesn't mean it's a good idea to stop making it better. Hence, this thread, to try and get some community involvement in the theory behind the RFS lag problem. We still don't really know what's causing it though, only that it is more than likely related to fsync. :(
[Galaxy S I9000 General] dirk1978:
I don't pretend to know anywhere near as much as you about this kind of stuff but from my own experience of being a Linux sysadmin for 13 years I can state categorically this is not true. Many times an ext2 fs will be corrupted even after an fsck that apparently passes, or in many cases the fsck will find so many errors it will end up corrupting the fs anyway. I've never had the slightest hint of fs corruption with ext3 / ext4 with journalling on.

Cheers for the OCLF by the way. It really helped my Eclair firmwares but seems to make no difference on the Froyo firmwares, which seems to point to this whole issue being a bit more complicated than we're appreciating here.
[Galaxy S I9000 General] RyanZA:
There is a lot of difference in traditional spinning media compared to MoviNAND, that does seem to make it act a bit differently. You are right though, and theoretically EXT3/4 is going to be safer than EXT2 when resizing files and similar tasks. In practice though, I haven't been able to cause the types of traditional disk fails on EXT2+MoviNAND as you would easily get on a spinning disk+power cut.

It comes down to a choice of reliability vs speed in the end though, I think. I personally would choose speed, but many (MANY) would choose the reliability. :)

As far as Froyo+OCLF, OCLF definitely helps out a lot in Froyo still. Try out any application that does heavy database work with and without OCLF for a very hands-on approach as to the difference. :D
[Galaxy S I9000 General] Chainfire:
Wee well let me throw a few thoughts out there as well. I haven't seen curio's promised "colorful" response yet, still waiting patiently ;)

I'm not sure whether the fsyncs are the source of the issue or not. It would require a lot more investigation. What I do know is (a) the various lag fixes help a lot - compare setting up 5 exchange email accounts with 30 day sync and over 100 mails a day per account between stock and lagfix, the difference is about an hour - (b) ext2 corrupts all over the place.

Don't get me wrong, ext2 mostly works fine, especially when you use the phone as it's meant to be used. However as I myself code "shady" stuff all day, I do a lot of reboots and battery pulling. I have suffered from irrepairable ext2 corruption repeatedly, sometimes multiple times a week, and these have been causes for having to reflash for me - which is actually the mean reason I developed the new rooting method for JPH and JPK, to make that process quicker and be able to use CWM for the setup I want.

Sometimes (rarely though) it happens even without improper reboots and battery pulls. One boot it simply won't boot up right, stuff will be missed, and the e2fsck output will report a bunch of garbage.

I'm not sure about ext4, I personally haven't used it yet. However, any claims that ext2 does not corrupt should be taken with at least an entire bag of salt, because I know from experience it does.

This is also the reason that if you do not have a phone that comes with the "3 finger salute" for recovery mode, you should really refrain from using hacks like these (or anything that might potentially mess with the boot process, really)

PS: definitely agree on Froyo though, the various lagfixes still improve much
[Galaxy S I9000 General] K4P1:
Oh, sorry. My mistake. Now I remenber you said it somewhere else (that it is awesome etc.).

ps. I use OCLF (fw JPK with XEE CSC)
[Galaxy S I9000 General] RyanZA:
Cool, thanks! :D I haven't been able to replicate it! Still! (Pulls out battery again... nope, still fine :/)

But it's good to hear that it definitely can corrupt. Do you know of any repeatable way to cause it? Just pulling out the battery doesn't seem to do it. The reason I ask is that I'd like to try the same with various filesystems (BTRFS, FAT32, etc etc) to see which ones are most resistant to corruption.
[Galaxy S I9000 General] Segitz:
Well... do some random writes on your device and pull out the battery... that should work.

And I'd suggest against BTRFS at the moment. I tried it on my laptop some weeks ago, and it was horribly slow (well, I did use encryption too). Even apt-get upgrades took forever... and the cause was... you guessed it right fsync()... using a differnt dpkg (available as a PPA for ubuntu) that disables many fsyncs, it runs MUCH faster. But also less secure, when there's power outage... but that won't matter on my laptop all that much^^

Either way... I have suffered numerous problems with filesystem problems, as I often use experimental software, which often also is very crash happy... thus I'll stay with ext4 for now. At least on my "production" systems.
[Galaxy S I9000 General] bilboa1:
then again BTRFS is not production ready

the fs is a critical part of the system, i wouldn't want to use it for anything but testing until the devs at least say it's ready

So many posts, so little time to read lol :(
[Galaxy S I9000 General] compuse:
Nobody could make it work on ntfs, jfs or hfs+?

I don't mind using a Paragon NTFS-like app/plugin for filetransfer, but i want to transfer files above 4.5GB to my phone, and maybe the lagprobs would be fixed with it right away?
[Galaxy S I9000 General] Chainfire:
Nope sorry, no reliable repeatable test that I know of, other than just doing it a LOT over a longer period.
[Galaxy S I9000 General] jutezak:
Some thought about flash file systems

From the Samsung v12 application notes docs, I gather there are two different things called RFS.

One RFS is a replacement (robust?) VFAT file system.

The other RFS is that same replacement VFAT filesystem layered onto XSR. XSR is a driver to make a oneNAND device look like a block device.

I suppose the SGS uses the first incarnation, as the MoviNAND handles the tasks of XSR.

RFS is supposed to be a 'robust FAT', compatible with normal FAT. I suppose, if one were to compile the normal VFAT driver into the kernel, it might work in place of RFS.

But RFS claims - in combination with XSR - to do free block management for the flash translation layer. Flash memory needs to know which erase blocks can be safely erased, and RFS communicates this to XSR if it is used. RFS could also communicate this to the Linux block device layer, if that has been patched to have this capability, and the OneNAND driver used also offers this. If so, that SHOULD lead to better long time performance.
[Galaxy S I9000 General] hardcore:
I think the stl* devices are OneNAND, and based on the Samsung docs RFS might be the best or only choice for them.

The mmbclk0 device should be a MoviNAND and we should be able to use any filesystem on that, but RFS might be the safest choice if it can do the free block management on MoviNAND too.
[Galaxy S I9000 General] RyanZA:
RFS definitely is doing *something*, and it can't be just journaling because it's just too slow for it to be only doing that (unless the 'journal' is a direct copy of the data, but that doesn't seem to be the case). That means it may well be doing some type of block management on the MoviNAND that we don't know of. I hope not. :) Can anybody think of a way we could try work out what it's doing? I tried to work it out from the source, but I fail completely on the magic numbers and stuff. If we could get some kind of spec that explains all the magic numbers, it might be possible to work it out. I've seen a few 'porting' guides for RFS, but none of them really explain it. Or I just don't understand them very well.

Basically: RFS does stuff that takes a long time and it could be anything. ;)
[Galaxy S I9000 General] jutezak:
From the Samsung kernel patch:

+# CONFIG_RFS_FS_SYNC_ON_CLOSE is not set

This should make close not terribly slow. Note that a sync usually syncs the whole file system, not only the file being written. The name of this parameter reflects that.

+CONFIG_RFS_FS_DEBUG_LEVEL_1=y

Could slow down things, but then maybe not.

+CONFIG_RFS_FS_ERASE_SECTOR=y

Thus RFS is set up to issue erase commands. But it seems that BLKDISCARD and BLKSECDISCARD for MMC/SD were only proposed in july 2010, and they are not to be found in the Samsung patches. Thus I doubt something is happening in that regard.
[Galaxy S I9000 General] yc1437:
Some questions to hiligh

1. Is or are there any samsung phone using rfs and no lag issue and why? Why not benchmark that if the answer is yes?

2. Is sgs lag real root cause is rfs or a hardware flaw?
[Galaxy S I9000 General] RyanZA:
Cant answer your first question, but a resounding yes, rfs causes the lag since EXT on the same hardware doesnt lag
[Galaxy S I9000 General] andrewluecke:
Agreed.. The only way I can think of is proper profiling tools, and I haven't seen any (but I don't really do mobile development). Maybe enabling some debugging in the kernel might help.

Dtrace/Systemtap with kernel probes could be awesome though if they were possible..
[Galaxy S I9000 General] etking:
ext2 w/o Journalling: After an unclean shutdown (as every simple adb reboot command from an app or widget is) at the same time as filesystem activity, the filesystem check may not be able to restore all the filesystem information completely, especially if larger files are written or changed. So there is a potential chance for data loss. If you don't believe it, try it out!
[Galaxy S I9000 General] RyanZA:
I don't want to be snarky, but I definitely have tried it out! A LOT!

The only way I've been able to get data corruption is to begin copying a large file, and then pull the battery out halfway through the transfer. This ends up with the file being corrupted when I put the battery back in. The problem is, if I do the same in EXT4 with journaling I get the exact same results.

So while there is a potential chance for data loss, I've been having A LOT of difficulty replicating that data loss! I'm basically of the opinion that while EXT2 does have a lot of potential data loss issues, in regular usage of the phone you're never going to see these issues in nearly all cases. That being the case, I am personally going to be using EXT2 from now on in my phone (or EXT4 with journals disabled, it's the same thing but a bit slower) because the performance benefits are more than worth it FOR ME. :) Obviously, everyone should choose the performance/reliability compromises that are best for them.

I think the EXT+journal vs EXT+no journal argument is pretty much finished at this point. Let's move onto other stuff now, and people who want more performance can use EXT2, while those who want more reliability can use EXT4. :)
[Galaxy S I9000 General] MiG123:
one thing you guys might wanna note... do you all realize that everytime a fresh flash is done (flashing firmware etc), the rfs filesystem is blazing fast? only upon prolonged usage does the filesystem start to become sluggish so could it be that rfs is corrupting and slowing the filesystem somewhere? also, once the entire filesystem is totally replaced with ext (i.e voodoo), this long term lag issue totally disappears/improves remarkably.

As such, I'm proposing that we also widen our focus to the long term performance degradation issue instead of just occupying our thoughts with the lag per se. Such a shift in thinking might yield some insight into why the rfs system degrades itself with time which we can then link back to the performance issues that we're experiencing.

Anyways, i'm no linux or filesystem expert here so the above are just my observations of the symptoms exhibited by the phone and my personal, not tech opinions about them....
[Galaxy S I9000 General] andrewluecke:
My unproven thoughts about the corruption theory is that it's wrong.. When it was discovered, I recall people saying that Samsung don't run fsck on startup. Doesn't it strike you as odd that plenty of errors are detected, BUT, Samsung aren't using that fsck app? Furthermore, the app is named fsck_msdos, not fsck_rfs.

My feelings are that the file was left-over from previous development (maybe from the nexus one), and I agree with Ryan, and believe it simply messes with the journal, or the speedup is more likely because the phone just booted. Furthermore, if corruption were the cause, why aren't we seeing mobile phones committing suicide, because of data being corrupted?

The Fsync theory seems more plausible at this time, or bugs in the driver. The harsh reality is though, we don't have enough basic information. We need tools to do it, and more information.

Switching to EXT4 might work around the problem, but it doesn't locate it's root cause.. Furthermore, long term, if Samsung uses RFS, if the problem with RFS is isolated, long term maintenance might be easier. If it's a RFS issue though, it's likely Samsung are working on it.
[Galaxy S I9000 General] DamianGto:
This is something i do think about to. I don't think the filesystem is the root of the problem. It something that rfs do. That problem should be focus on. But i know you looking at that, but sometimes you are looking more on what filesystem is best.

But i follow this topic with great interest.
[Galaxy S I9000 General] Phk:
Mig123 - When the SSD is clean (new ROM) there's no need for internal maintenance by the IO firmware because there are few files and all were written in a sequenced way. This explains why ROMs are fast at the beginning!

Ryan ryan ryan, always "the man" :) You rock bro.. btw THANKS for finally explaining me what tha hell was happening with RFS.. fsync should never be on all fcloses, except when you really need Consistency.

(A) -> I also agree that this IS the solution. You just can't keep loosing important things like journaling and fsyncs... My "worst case scenario" is that the hardware itself is not adequate and needs a lot of small, internally-cached operations for reordering tracks. Remember the capacitors? Rings a bell? I think the MoviNAND hardware really really sucks :)

(B) -> Well, we could live on the bleeding-edge speed and schedule fsyncs once in a while.. like when screen is turned off for 5 mins.. Anyway, remember that consistency is important... for example, remember my problems with bluetooth when using OCLF and not when using VOODOO? I've managed to catch a sqlite output message about "contacts2.db" beeing a corrupted contacts file..

I share the opinion of Speed >better than> consistency, but the sad news is: It's wrong. Consistency must be a premise.. The "C" letter is a must at the transactional "ACID" =)
[Galaxy S I9000 General] RyanZA:
I don't think the MoviNAND hardware sucks at all, I think it just tries to be so smart it ends up being dumb. ;)

As far as consistency, I'm not sure if your bluetooth issue was a filesystem issue, simply because it happened even without restarting the device. EXT2 (or any filesystem) is not going to corrupt while the device is running, it will only corrupt on unclean shutdown. :)

That's really where filesystem consistency becomes a problem -- unclean shutdown. If you aren't pulling the battery out while the phone is running, and the OS isn't crashing, then it won't matter what filesystem you're using, it will never corrupt (except for maybe BTRFS which is a bit beta ;) ). When the device does suddenly lose power though, a better filesystem will help prevent corruption. (it won't ever be 100% simply because power can be lost halfway through writing a large file).

So basically for EXT4 vs EXT2 you are giving up speed for data security when power is lost. This is important since power can be lost at any time, but it's still a personal choice as to whether or not that speed / safety tradeoff is worth it. :)
[Galaxy S I9000 General] Phk:
LOL it can be :)

After a *certain* boot, BT would never work OK again.. And before DMESG yells a lot about BT problems and errors, the first Error message is "contact database file corrupted"... It really smells like the lack of an FSync, assymetry between data and meta-data!

Cheers Ryan!! Keep it up! :)
[Galaxy S I9000 General] mathieumeuh:
RFS Application note

Here is a document from Samsung explaning how the RFS works and why it's the best filesystem ever ! LOL
[Galaxy S I9000 General] RyanZA:
I think we can ignore that document as fiction! Haha!
[Galaxy S I9000 General] mmorselli:
So, the Galaxy TAB (that uses RFS too) have a chance ? :p
[Galaxy S I9000 General] AnnihilatorSC:
Should be rather simple detective work: JM8 lags, JM9 doesn't lag, JPM lags.

It all comes down to finding the difference between them; comparing JM8 to JM9 should be, at least in theory, the easiest route.
[Galaxy S I9000 General] DamianGto:
I do have jpm and it don't lag at all.

But its the rfs Filesystem that do the lag. Remove part of it with Z4mod and you get a phone that is fast and lagfree
[Galaxy S I9000 General] appagom:
hi Ryanza. edit.. First nice explanations, I learned something. Now, I'm not an expert, but I've used ext2 and ext3 for years (EXACTLY identical except for the journal.. remove an ext3 journal and you have ext2.) Saying that testing 10 times on large files and both fail is a bit over-simplified in my mind (and maybe you are just sparing words). Neither can complete incomplete file transfers as far as I know, true. However as far as I can tell the journal does not simply remove the need for a full disk check as you've implied with the supporting quote. It actually contains information about HOW to recover broken blocks and inodes (not entire large files), whereas the disk check only finds them and brute force changes them into something low-level legitimate but occasionally wrong (like shared blocks simply getting cloned.. that one's always scary and I suspect is the nastiest fix)

After years of using both, no doubt in my mind ext3(and probably 4) is more stable on heavy desktop use over long times. With ext2 every time it found errors, I held my breath for the next day to see if the system was still stable. Sometimes it wasn't. (edit: with ext3 I'm not even very nervous to pull the plug on a mostly idle system) That said, I'd still be willing to use ext2 on a cell phone if performance goes way up. It's just a cell phone. Also the underlying rfs journal should still provide some protection I would think, just not as much since it doesn't know about the ext2 structure.
[Galaxy S I9000 General] DamianGto:
You must understand that it not a moving disc on the phone.

With the overhead of ext 3-4 you just make things slower.

You don't need that on sgs.

Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram