[REF] Ext4 speed improvement with a safe mount option on /data

---

Hey everyone.

As I spend some time on studying Ext4 for the Galaxy S devices, working on Voodoo lagfix, and based on what I saw in mount logs it's possible that the performances could be increased without altering data integrity nor filesystem integrity in case of crash.
On /data, noauto_da_alloc is not used.

This option activates a sort of Ext3 emulation mode, which force sync on write close without sync.

It also comes with a speed penalty for SQLite writes, and is unneccessary when hardware barriers are enabled.
Barriers allow usage of delayed allocations without risk. Delayed allocations are the key to performance for modern filesystems.

as root:

mount -o remount,noauto_da_alloc /data /data

You can count on me to cook a kernel with this mount option as default

PS: this option is already used in Voodoo kernels for Galaxy S devices / has been chosen after extensive performance and reliability tests.

Okay, kevin_teslacoil run quadrant:

before:
<kevin_teslacoil> 1676 for the full quadrant bench mark


after:
<kevin_teslacoil> interesting
<kevin_teslacoil> 2422 this time
<GuiPer> :eek:
<Ibanez33> wtf?

I'm not a fan of quadrant, but used as a tool, it can give some useful infos
Also, note that this dramatic change in benchmark result won't be as incredible in real life usage.
But still, it's a better choice of configuration, using the filesystem driver like it should be given the hardware parameters.

Can this be implemented in Voodoo for SGS?

Reference, from man mount.

auto_da_alloc|noauto_da_alloc
Many broken applications don't use fsync() when noauto_da_alloc replacing existing files
via patterns such as

fd = open("foo.new")/write(fd,..)/close(fd)/ rename("foo.new", "foo")

or worse yet

fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).

If auto_da_alloc is enabled, ext4 will detect the replace-via-rename and replace-via-trun‐
cate patterns and force that any delayed allocation blocks are allocated such that at the
next journal commit, in the default data=ordered mode, the data blocks of the new file are
forced to disk before the rename() operation is commited. This provides roughly the same
level of guarantees as ext3, and avoids the "zero-length" problem that can happen when a
system crashes before the delayed allocation blocks are forced to disk.

I'm trying this now.

Originally Posted by jaju123

Can this be implemented in Voodoo for SGS?

It's already implemented in Voodoo

Okay thanks

Still at it I see?

We lose this whenever we reboot I'm assuming?

Quadrant scores:
Before: 1672
After: 2334

Cook this into some good 1.2GHz OC/UV

We already know the Hummingbird can potentially hit 1.6

Its late, nevermid