Reality behind RFS Lag

Search This thread

RyanZA

Senior Member
Jan 21, 2006
2,023
780
JHB
This is probably missing a lot of facts that we haven't uncovered yet. When we learn more, we can update what we know here

Background

All data is stored on an 8gb or 16gb MoviNAND chip, of which 2GB is 'system data', and the rest is for user storage. The MoviNAND is one of the first mobile 'smart SSD' chips. That means that the MoviNAND handles all operations such as data wear leveling, physical data lookup, as well as having it's own internal buffers. This cleverness is both good... and very bad.

FSYNC

When writing data to disk, your system and apps will make a call to the driver to 'write some data to file X'. This data will then be placed into kernel filesystem buffers and streamed off as commands to the MoviNAND. The MoviNAND will then slowly accept these commands, and place them into its own buffer, and the disk controller itself will then go about it's business writing this data to disk, using lookup tables to determine where to write the data to ensure maximum NAND lifetime, etc. It does a lot of work.

The system or apps also have an extra tool, called FSYNC. When this is used, the kernel and filesystem will clear the buffer for the affected file, and ensure it is written to disk. The current thread will block, and wait for the fsync call to return to signal that the data is fully written to disk. The kernel itself will wait for an event from the MoviNAND to signal that the data has been completely written.

In a 'dumb' disk, this fsync is fairly quick - the kernel buffer will be written directly to where the kernel has directed, and the round trip time (RTT) will be as long as it takes for data to be written.

In a 'very smart' desktop SSD, the fsync can return instantly - the disk controller will take the data and place it in it's battery-backup protected, and then go about it's wear leveling and writing in the background without bothering the system.

In the 'smart' MoviNAND, the fsync will take a very very long time to return - sometimes fsync on MoviNAND will take several seconds(confirm?) to return. This is because the MoviNAND may have a long line of housekeeping tasks waiting for it when a fsync is called, and it will complete all of it's tasks before returning.

RFS

RFS has a fairly badly written driver, that will call an fsync on file close.

Basically, RFS runs in 'ultra secure' mode by default. This security may not be really needed - I personally don't want it if it means enormous slow downs. It also doesn't help data security if the system/app is holding a file open, only if it closes the file. The MoviNAND is also fairly smart, and appears to write it's cache to disk before turning off, and also appears to have capacitors to keep it alive for a little bit of time in the event of a power cut.

SQLite

Most Android apps use SQLite - a fairly simple database that is easy to embed. Sqlite has 'transactions' - not real transactions, but a transaction in sqlite is where the database is locked for the duration of a database write, and multiple databases writes can be included in one transaction. At the end of a transaction, sqlite will call FSYNC on the database file, causing a possibly long wait while the MoviNAND does it's thing. Certain applications will not bunch up writes into a single transaction, and will do all of their writes in new transactions. This means that fsync will be called again and again. This isn't really a problem on most devices, as fsync is a very fast operation. This is a problem on the SGS, because MoviNAND fsync is very slow.

The various fixes and why they work

Native EXT4 to replace RFS (Voodoo)

By replacing RFS with EXT4, the 'sync on fileclose' problem is removed. The EXT series of filesystems is also more efficient at allocating information into blocks than RFS/FAT32 is. This means less real writes to MoviNAND, which means that the MoviNAND buffer should be smaller, and when a sync is called, fewer commands have to be run. When a sync is called on EXT4, it will still be very slow, as the MoviNAND's sync is still slow.
Basically, EXT4 improves filesystem grouping which leads to less commands, and does not have the broken 'sync on file close' that RFS does. It will not heavily improve sqlite database access in certain apps, as the full fsync on transaction end will still have to go through MoviNAND, and will be slow.

When pulling out the battery, there is a chance to lose data that has been written to a file but has not yet been told to sync to disk. This means that EXT4 is less secure than RFS. However, I believe the performance to be worth the risk.

Loopback EXT2 on top of RFS (OCLF)

By creating a loopback filesystem of EXT2, the 'sync on fileclose' problem is removed as well. Since the Loopback File is never closed until the EXT2 is unmounted, RFS will not call fsync when a file in the EXT2 loopback is closed. Since a single large file is created on RFS instead of multiple small files, RFS is unable to mis-allocate the file, or fragment it. The actual allocation of filesystem blocks is handled by EXT2. As a note, care should be taken in making the large file on RFS - it MUST align correctly with the MoviNAND boundries, or operations will be slowed down due to double-disk accesses for files, etc. It is unknown whether OCLF is aligning this correctly (how to determine this? 4KB block size gives double the performance of 2KB block size, so it might be aligning it correctly already).

Loopback also has the benefit of speeding up Sqlite databases (at the expense of a transaction being lost in power outage, as it could still be in ram). As always, this is a performance tradeoff between data security when the battery is pulled out, and performance. When pulling a battery out while using the loopback filesystem, there is a chance to lose the last few seconds of database writes. In practice, this isn't a huge deal for a mobile phone - most lost data will be resynced when the phone reboots. In my opinion, the performance is worth it because of the very slow speed of a sync on MoviNAND.

Loopback EXT2 on top of EXT4

All of the above for normal loopback EXT2 applies. In addition, when the loopback flushes data, it will be flushed to EXT4 instead of RFS. This will probably be better than flushing to RFS, as the RFS driver is not as well written as the EXT4 driver. The difference should not be very large, though.

Journaling

Journaling on an SSD is not required. Your data will not be lost, your puppy will not die. Here is a post made by Theodore Tso - http://marc.info/?l=linux-ext4&m=125803982214652&w=2
But there will be some distinct tradeoffs with
omitting the journal, including possibility that sometimes on an
unclean shutdown you will need to do a manual e2fsck pass.
Not using a journal is not a big deal, as long as you take care to do a full e2fsck pass when an unclear shutdown has occurred. This is the main reason for a journal - to prevent the need to do a full disk check, and instead the journal can be easily read, and the full disk check avoided.

EXT2 vs EXT4

EXT2 appears to work better on the SGS than EXT4. This is because EXT4 has more CPU overhead than EXT2. Journaling is also very bad on MoviNAND. Why? It appears to be the command buffer in the MoviNAND controller. A call to update the journal will use a command slot in the MoviNANDs buffer, that could otherwise have been used for a real disk write. This means that journaling on MoviNAND is a VERY expensive operation compared to journaling on a 'dumb' disk.

Well, you could technically use EXT4 and simply disable the high cpu and other features until you are left with EXT2, since EXT4 and EXT2 are basically the same thing.

At any rate, the difference between EXT4 and EXT2 is not very large, and there's no need for flamewars over it - it comes down to a choice of 'running' performance vs 'startup' performance, with EXT2 edging out EXT4 for everyday speed, while EXT4 not required a long disk check at boot.

Future Work

Rewrite the firmware for the MoviNAND's flash to handle fsyncs properly and not bring the system to it's knees. I joke, but this is really the true solution.

Other solutions include hacking EXT's fsync method to return instantly, and ensuring that the real fsync is called when the system shuts down. Or doing nothing, fsync is there for a reason, I guess, and would be fine if MoviNAND's fsync wasn't so very slow.

There is probably a lot of small details missing from this writeup. They'll be updated when we learn more. :) Thanks for all the useful discussions and arguments, everyone!
 

psphknxp

Member
Aug 12, 2010
19
2
HKSAR
Thanks RyanZA a lot and it's good thread to all SGS users to understand what's we're running!

Keep on going!
 

dakine

Senior Member
Nov 13, 2006
748
34
Excellent post, it seems like you enjoy figuring this stuff out. Reading about it like this even gets me interested. Samsung would do well in hiring more people like you.
 
Feb 11, 2009
10
0
Thanks RyanZA. You are a impressive coder with so much information.

thanks for sharing and hope that we can get it fix forever and get the desire HD rom for us.
 

msri3here

Senior Member
Aug 27, 2010
462
130
Pune
Thanks dude...
being a techy guy, enjoyed reading your post and very nice to know the details of the file system...
Looking forward to your future work and updates :)
 

ykkfive

Inactive Recognized Developer
Jul 25, 2010
3,181
2,992
ykkfive.blogspot.com
ryanza, u crazy guy (again!! :D), u did a good job. it should be clear enough for ppl to decide which fs is a better choice for their particular uses.

and , in fact, i've tried all of them. ext4 is far more cpu extensive, and caused a lot of lags when i was listening to mp3s while surfing the internet. ext3 is the modest one, while ext2 is very fast with the expense of "possible data loss".

for the ext fs over loop devices, it seems there is no impact on performance issue, as well as the noatime and nodiratime mount options, although theoritcally they should increase the performance a bit by skipping the atime and diratime jobs
 

cantIntoCode

Retired Recognized Developer
Aug 29, 2010
1,629
2,564
Glasgow
Thanks for the huge breakdown. Very informative. Hopefully someone sorts out this non sense in the near future. Looking forward to see what happens :)
 

RyanZA

Senior Member
Jan 21, 2006
2,023
780
JHB
ryanza, u crazy guy (again!! :D), u did a good job. it should be clear enough for ppl to decide which fs is a better choice for their particular uses.

and , in fact, i've tried all of them. ext4 is far more cpu extensive, and caused a lot of lags when i was listening to mp3s while surfing the internet. ext3 is the modest one, while ext2 is very fast with the expense of "possible data loss".

for the ext fs over loop devices, it seems there is no impact on performance issue, as well as the noatime and nodiratime mount options, although theoritcally they should increase the performance a bit by skipping the atime and diratime jobs

It really doesn't seem that ext2 has any "possible data loss". ext2 DOES have possible "long boot up time while doing filesystem checks", but the actual data itself will be the same across all ext2,3,4. You need to use ext2 if the long bootup isn't a problem for you, but if you reboot your phone frequently then ext3,4 would be a better choice since the bootup will be far quicker! An EXT2 partition can take over 5 minutes to boot if things go badly, while an EXT3,4 should never take longer than about 10 seconds.

Data loss, if any, would be identical between EXT2,3,4 though, so don't worry about the data, only the boot up time!

RFS has been around for a bit and is used on other phones do those phones have the same lag issues as the sgs?

Not sure if it helps but I stumbled on this:


http://www.samsung.com/global/busin...ionmemory/downloads/RFS_130_Porting_Guide.pdf

http://movitool.ntd.homelinux.org/trac/movitool/wiki/RFS

The issue is fairly specific to Linux+RFS+MoviNAND - it is the way the RFS linux drivers interact with MoviNAND that seems to cause the big black screens. I don't have any other RFS devices though, so I can't test it myself.

Interesting.. How did you work these behaviors out, by checking the code?

I checked the sqlite code... but as far as the rest, it's mostly from reading the MoviNAND spec, and investigations and tests by myself and others on the RFS filesystem properties, etc. So not so much the code, because the code itself for the RFS driver is practically illegible and I barely understand it. (Magic numbers everywhere! What do they mean?)

EDIT: I'd like to add that there are no doubt missing facts in what I've written, as well as errors as to the cause of certain things. We'll eventually get this all worked out though. This doc represents the current 'All we know' about the RFS lag issue. That doesn't mean there isn't more we can still learn - I'm sure there is. If you find any inconsistencies in this, please share them so we can try and work out the truth!
 

hardcore

Senior Member
Sep 12, 2006
3,435
7,990
There are also several things that can be done to speed up RFS.

One obvious thing is to remount the partitions using the "noatime" option instead of the default "relatime". This should reduce writes-after-reads.

Tweaking the CFQ io scheduler helps tremendously. I have:

for i in $(ls -1 /sys/block/stl*) $(ls -1 /sys/block/mmc*) $(ls -1 /sys/block/bml*) $(ls -1 /sys/block/tfsr*)
do echo "0" > $i/queue/rotational
echo "1" > $i/queue/iosched/low_latency
echo "1" > $i/queue/iosched/back_seek_penalty
echo "1000000000" > $i/queue/iosched/back_seek_max
echo "0" > $i/queue/iosched/slice_idle
echo "50" > $i/queue/iosched/slice_sync
echo "20" > $i/queue/iosched/slice_async
done

Just for testing, I've tried remounting the /cache RFS partition as VFAT (FAT32), and it makes sequential writes to the same partition about 2x faster. But I think we cannot remount the /data and /dbdata partitions as VFAT.
 
Last edited:

ykkfive

Inactive Recognized Developer
Jul 25, 2010
3,181
2,992
ykkfive.blogspot.com
It really doesn't seem that ext2 has any "possible data loss". ext2 DOES have possible "long boot up time while doing filesystem checks", but the actual data itself will be the same across all ext2,3,4. You need to use ext2 if the long bootup isn't a problem for you, but if you reboot your phone frequently then ext3,4 would be a better choice since the bootup will be far quicker! An EXT2 partition can take over 5 minutes to boot if things go badly, while an EXT3,4 should never take longer than about 10 seconds.


no, ext2 did caused some data loss. i ran fsck on a ext2 parition once and it returned some unfixable blocks!

for the boot up time, i used to have include the fsck when the phone boot up b4, but i removed it already since, "for me", those "possible data losses" are insignificant. and no matter whether i pick ext2/3/4, the reboot time is about 30 secs
 

RyanZA

Senior Member
Jan 21, 2006
2,023
780
JHB
no, ext2 did caused some data loss. i ran fsck on a ext2 parition once and it returned some unfixable blocks!

for the boot up time, i used to have include the fsck when the phone boot up b4, but i removed it already since, "for me", those "possible data losses" are insignificant. and no matter whether i pick ext2/3/4, the reboot time is about 30 secs

Those unfixable blocks would be unfixable under any EXT variant - the unfixable block is basically a block that was partially written to disk before power was cut, and therefore the checksum doesn't add up. This can happen regardless of ext2/3/4, and the data is lost under all of them (because the data was never fully written to disk). The only way to avoid this is to do a proper shutdown of the system, and not pull the battery. In EXT3/4 with journaling, the journal would simply indicate that the write to that block did not complete. In EXT2, there is no journal, so the filesystem check must trawl it's way through the entire disk and discover for itself that the data wasn't written. In both cases, the data is gone (since it was never there), but in EXT3/4 the process is much quicker. In EXT2 you'd be sitting waiting for the phone to boot up while it checks it.

The tradeoffs are very very straight forward: fast boot + slower speed vs slow boot + slightly faster speed. Not much to it.

EDIT: Not running the fsck at all on EXT2 could be bad, eventually the disk may become unmountable, and your phone won't boot. I'd say either do the check on boot and suffer the wait, or use journaling. :)
 

captive

Senior Member
Dec 30, 2009
161
36
There are also several things that can be done to speed up RFS.
One obvious thing is to remount the partitions using the "noatime" option instead of the default "relatime". This should reduce writes-after-reads.
Tweaking the CFQ io scheduler helps tremendously. I have:.
I already had the noatime trick on my sgs, but didn't know about the cfq tweakings. Can you explain what exactly they do?
 

RyanZA

Senior Member
Jan 21, 2006
2,023
780
JHB
Tweaking the CFQ io scheduler helps tremendously. I have:

Tweaking the CFQ io scheduler helps a lot, but it has a problem: When an FSYNC is called, the app will wait until the fsync returns. No matter how you tweak the scheduler, you won't be able to get around the app sitting there waiting for all pending disk operations in the MoviNAND to complete. This gets worse and worse as much applications are running at once, since there is more for the MoviNAND to do on each sync.

So yeah, scheduling does help a bit, but it doesn't defeat the core problem. :)

BTW, if you're using Froyo and want a quick way to put in some sane CFQ scheduler settings, just set the scheduler option in the OCLF app to 'CFQ' and tick 'set on boot' - when the scheduler gets changed, Linux will put it's defaults back in and override Samsung's strange settings, which means you end up with something fairly close to what hardcore is setting here. :)
 
  • Like
Reactions: slickytru5

AXIS of Reality

Senior Member
Mar 15, 2010
184
40
Brisbane
I have 1 question.......:

WHY HASN'T SAMSUNG HIRED YOU YET?!

Seriously, Samsung should be able to figure that out for their own hardware and software, so why would they proceed this way if they were aware of these issues?
 

ykkfive

Inactive Recognized Developer
Jul 25, 2010
3,181
2,992
ykkfive.blogspot.com
Those unfixable blocks would be unfixable under any EXT variant - the unfixable block is basically a block that was partially written to disk before power was cut, and therefore the checksum doesn't add up. This can happen regardless of ext2/3/4, and the data is lost under all of them (because the data was never fully written to disk). The only way to avoid this is to do a proper shutdown of the system, and not pull the battery. In EXT3/4 with journaling, the journal would simply indicate that the write to that block did not complete. In EXT2, there is no journal, so the filesystem check must trawl it's way through the entire disk and discover for itself that the data wasn't written. In both cases, the data is gone (since it was never there), but in EXT3/4 the process is much quicker. In EXT2 you'd be sitting waiting for the phone to boot up while it checks it.

The tradeoffs are very very straight forward: fast boot + slower speed vs slow boot + slightly faster speed. Not much to it.

EDIT: Not running the fsck at all on EXT2 could be bad, eventually the disk may become unmountable, and your phone won't boot. I'd say either do the check on boot and suffer the wait, or use journaling. :)

yes i know the risk for not fsck the disks, but it is "under control" and i am prepared to do a reflash when needed :D
 

Adevem

Senior Member
Aug 4, 2010
1,339
85
it's this awesome community and it's works that keeps me from selling this phone lol.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 7
    This is probably missing a lot of facts that we haven't uncovered yet. When we learn more, we can update what we know here

    Background

    All data is stored on an 8gb or 16gb MoviNAND chip, of which 2GB is 'system data', and the rest is for user storage. The MoviNAND is one of the first mobile 'smart SSD' chips. That means that the MoviNAND handles all operations such as data wear leveling, physical data lookup, as well as having it's own internal buffers. This cleverness is both good... and very bad.

    FSYNC

    When writing data to disk, your system and apps will make a call to the driver to 'write some data to file X'. This data will then be placed into kernel filesystem buffers and streamed off as commands to the MoviNAND. The MoviNAND will then slowly accept these commands, and place them into its own buffer, and the disk controller itself will then go about it's business writing this data to disk, using lookup tables to determine where to write the data to ensure maximum NAND lifetime, etc. It does a lot of work.

    The system or apps also have an extra tool, called FSYNC. When this is used, the kernel and filesystem will clear the buffer for the affected file, and ensure it is written to disk. The current thread will block, and wait for the fsync call to return to signal that the data is fully written to disk. The kernel itself will wait for an event from the MoviNAND to signal that the data has been completely written.

    In a 'dumb' disk, this fsync is fairly quick - the kernel buffer will be written directly to where the kernel has directed, and the round trip time (RTT) will be as long as it takes for data to be written.

    In a 'very smart' desktop SSD, the fsync can return instantly - the disk controller will take the data and place it in it's battery-backup protected, and then go about it's wear leveling and writing in the background without bothering the system.

    In the 'smart' MoviNAND, the fsync will take a very very long time to return - sometimes fsync on MoviNAND will take several seconds(confirm?) to return. This is because the MoviNAND may have a long line of housekeeping tasks waiting for it when a fsync is called, and it will complete all of it's tasks before returning.

    RFS

    RFS has a fairly badly written driver, that will call an fsync on file close.

    Basically, RFS runs in 'ultra secure' mode by default. This security may not be really needed - I personally don't want it if it means enormous slow downs. It also doesn't help data security if the system/app is holding a file open, only if it closes the file. The MoviNAND is also fairly smart, and appears to write it's cache to disk before turning off, and also appears to have capacitors to keep it alive for a little bit of time in the event of a power cut.

    SQLite

    Most Android apps use SQLite - a fairly simple database that is easy to embed. Sqlite has 'transactions' - not real transactions, but a transaction in sqlite is where the database is locked for the duration of a database write, and multiple databases writes can be included in one transaction. At the end of a transaction, sqlite will call FSYNC on the database file, causing a possibly long wait while the MoviNAND does it's thing. Certain applications will not bunch up writes into a single transaction, and will do all of their writes in new transactions. This means that fsync will be called again and again. This isn't really a problem on most devices, as fsync is a very fast operation. This is a problem on the SGS, because MoviNAND fsync is very slow.

    The various fixes and why they work

    Native EXT4 to replace RFS (Voodoo)

    By replacing RFS with EXT4, the 'sync on fileclose' problem is removed. The EXT series of filesystems is also more efficient at allocating information into blocks than RFS/FAT32 is. This means less real writes to MoviNAND, which means that the MoviNAND buffer should be smaller, and when a sync is called, fewer commands have to be run. When a sync is called on EXT4, it will still be very slow, as the MoviNAND's sync is still slow.
    Basically, EXT4 improves filesystem grouping which leads to less commands, and does not have the broken 'sync on file close' that RFS does. It will not heavily improve sqlite database access in certain apps, as the full fsync on transaction end will still have to go through MoviNAND, and will be slow.

    When pulling out the battery, there is a chance to lose data that has been written to a file but has not yet been told to sync to disk. This means that EXT4 is less secure than RFS. However, I believe the performance to be worth the risk.

    Loopback EXT2 on top of RFS (OCLF)

    By creating a loopback filesystem of EXT2, the 'sync on fileclose' problem is removed as well. Since the Loopback File is never closed until the EXT2 is unmounted, RFS will not call fsync when a file in the EXT2 loopback is closed. Since a single large file is created on RFS instead of multiple small files, RFS is unable to mis-allocate the file, or fragment it. The actual allocation of filesystem blocks is handled by EXT2. As a note, care should be taken in making the large file on RFS - it MUST align correctly with the MoviNAND boundries, or operations will be slowed down due to double-disk accesses for files, etc. It is unknown whether OCLF is aligning this correctly (how to determine this? 4KB block size gives double the performance of 2KB block size, so it might be aligning it correctly already).

    Loopback also has the benefit of speeding up Sqlite databases (at the expense of a transaction being lost in power outage, as it could still be in ram). As always, this is a performance tradeoff between data security when the battery is pulled out, and performance. When pulling a battery out while using the loopback filesystem, there is a chance to lose the last few seconds of database writes. In practice, this isn't a huge deal for a mobile phone - most lost data will be resynced when the phone reboots. In my opinion, the performance is worth it because of the very slow speed of a sync on MoviNAND.

    Loopback EXT2 on top of EXT4

    All of the above for normal loopback EXT2 applies. In addition, when the loopback flushes data, it will be flushed to EXT4 instead of RFS. This will probably be better than flushing to RFS, as the RFS driver is not as well written as the EXT4 driver. The difference should not be very large, though.

    Journaling

    Journaling on an SSD is not required. Your data will not be lost, your puppy will not die. Here is a post made by Theodore Tso - http://marc.info/?l=linux-ext4&m=125803982214652&w=2
    But there will be some distinct tradeoffs with
    omitting the journal, including possibility that sometimes on an
    unclean shutdown you will need to do a manual e2fsck pass.
    Not using a journal is not a big deal, as long as you take care to do a full e2fsck pass when an unclear shutdown has occurred. This is the main reason for a journal - to prevent the need to do a full disk check, and instead the journal can be easily read, and the full disk check avoided.

    EXT2 vs EXT4

    EXT2 appears to work better on the SGS than EXT4. This is because EXT4 has more CPU overhead than EXT2. Journaling is also very bad on MoviNAND. Why? It appears to be the command buffer in the MoviNAND controller. A call to update the journal will use a command slot in the MoviNANDs buffer, that could otherwise have been used for a real disk write. This means that journaling on MoviNAND is a VERY expensive operation compared to journaling on a 'dumb' disk.

    Well, you could technically use EXT4 and simply disable the high cpu and other features until you are left with EXT2, since EXT4 and EXT2 are basically the same thing.

    At any rate, the difference between EXT4 and EXT2 is not very large, and there's no need for flamewars over it - it comes down to a choice of 'running' performance vs 'startup' performance, with EXT2 edging out EXT4 for everyday speed, while EXT4 not required a long disk check at boot.

    Future Work

    Rewrite the firmware for the MoviNAND's flash to handle fsyncs properly and not bring the system to it's knees. I joke, but this is really the true solution.

    Other solutions include hacking EXT's fsync method to return instantly, and ensuring that the real fsync is called when the system shuts down. Or doing nothing, fsync is there for a reason, I guess, and would be fine if MoviNAND's fsync wasn't so very slow.

    There is probably a lot of small details missing from this writeup. They'll be updated when we learn more. :) Thanks for all the useful discussions and arguments, everyone!
    1
    Tweaking the CFQ io scheduler helps tremendously. I have:

    Tweaking the CFQ io scheduler helps a lot, but it has a problem: When an FSYNC is called, the app will wait until the fsync returns. No matter how you tweak the scheduler, you won't be able to get around the app sitting there waiting for all pending disk operations in the MoviNAND to complete. This gets worse and worse as much applications are running at once, since there is more for the MoviNAND to do on each sync.

    So yeah, scheduling does help a bit, but it doesn't defeat the core problem. :)

    BTW, if you're using Froyo and want a quick way to put in some sane CFQ scheduler settings, just set the scheduler option in the OCLF app to 'CFQ' and tick 'set on boot' - when the scheduler gets changed, Linux will put it's defaults back in and override Samsung's strange settings, which means you end up with something fairly close to what hardcore is setting here. :)
    1

    Hahah! :D

    Hey RyanZA,

    which FS do you personally prefer?

    Why not just use EXT3 to kill EXT4's online defragmentation which loads the cpu?

    Thanks ;)

    I personally use EXT2, and I've had zero issues with it so far. :)
    I would recommend either RFS for absolute safety, EXT4 with journaling for a good middle ground of quick boot ups and decent speed, or EXT2 for absolute performance.

    I would probably never use anything besides EXT2 myself (with the possible exception of reiserfs or one of the new experimental filesystems) on the SGS, as it works the best FOR ME.

    Obviously, if I learn otherwise that other filesystems are better, I'll be the first one jumping ship! I am always very very happy to admit if I am wrong about something. :)
    1
    Ryanza, this is specifically for you. Tried your lag fix and the voodoo. Voodoo is no where close to what u have come out with. But the lag is back. Better than voodoo but worse than stock eclair. On stock Indian froyo with oclf. Any suggestions?

    Sent from my GT-I9000 using XDA App
    1
    Until now anybody gave any irrefutabledata about ext2 vs ext4.
    I personally use ext4 on Damian RC4. And it's flies.

    Until i see any data i will prefer ext4 any day of the week.