[Dev Kernel] 2.6.29 Support for ext2/ext3/ext4/yaffs2

otrhodox · Aug 12, 2010

mimocan said:
mounting the /data partition as ext2 does not gain any speed. Done it, seen it.

either you go for the loopback solution, or the external sd solution.

Surely you mean mounting /data as ext2 is no faster than the existing loopback or external ext2 solutions, right?

Otherwise why on Earth does the loopback solution work at all? (RyanZA proved it was mostly due to a 4k block size on the fs, as I understand it.)

Aweb · Aug 13, 2010

Any news ? This looks like a much better idea than the current "fixes"...

ivanmmj · Aug 13, 2010

Unfortunately, I'm still failing to boot with my own progress. I'm not sure what I'm doing wrong...

andars05 · Aug 18, 2010

otrhodox said:
Surely you mean mounting /data as ext2 is no faster than the existing loopback or external ext2 solutions, right?

Otherwise why on Earth does the loopback solution work at all? (RyanZA proved it was mostly due to a 4k block size on the fs, as I understand it.)

I'm confused about this as well. Does this mean that the ext2 file is just acting as a buffer?

mekwall · Aug 18, 2010

andars05 said:
I'm confused about this as well. Does this mean that the ext2 file is just acting as a buffer?

A loopback device will use RAM as a buffer when writing/reading to/from it. I still cannot get how it can be so much faster even when writing/reading large amounts that exeeds available RAM... Maybe it has to do with that RFS thinks it's only one big file so there's not as much overhead as with a bunch of smaller files. Just a theory

andars05 · Aug 19, 2010

Okay, thanks!

Does this mean though that the I/O problem is hardware related then? mimocan stated that formatting the internal partition as ext2 didn't speed anything up. If I'm understanding this correctly, changing the filesystem from RFS to something else will not fix the I/O problem.

mekwall · Aug 19, 2010

andars05 said:
Okay, thanks!

Does this mean though that the I/O problem is hardware related then? mimocan stated that formatting the internal partition as ext2 didn't speed anything up. If I'm understanding this correctly, changing the filesystem from RFS to something else will not fix the I/O problem.

Exactly. This is why using an ext2 image is the best option (might even be the real permanent option) until we can see some kind of driver that will make more use of the RAM when buffering.

andars05 · Aug 19, 2010

Thanks once again!

How is it that when using tools like "Benchmark" from the Market phones such as the Nexus One have slightly slower read/write times, but writes files much faster? Eg.

Galaxy S:

Total file system score 70.81754
Creating 1000 empty files 41.438 sec << Why are these so high?
Deleting 1000 empty files 29.886 sec <<
Write 1M into file 3.5855145 M/sec < and why is this faster, even though creating the files is slower
Read 1M from file 138.88889 M/sec

Nexus One:

Total FS score 58.733284
Creating 1000 empty files 11.523s
Deleting 1000 empty files 8.169s
Write 1M into file 1.8835939 M/s
Read 1M from file 116.27907 M/s

Is it just that the N1 has a driver that helps to buffer the writes with the ram?

mekwall · Aug 19, 2010

I can only speculate. Probably it has to do with the nature of the RFS implementation (driver) and how it handles caching/buffering of small files. It shouldn't perform that bad, so hopefully Samsung will find a solution.

Sent from my GT-I9000 using XDA App

nrg · Aug 19, 2010

I could be because of blocksize as stated in the original thread.

Here is also an article about it:

Increase usb flash drive write speed

mekwall · Aug 19, 2010

nrg said:
I could be because of blocksize as stated in the original thread.

Here is also an article about it:

Increase usb flash drive write speed

That's been ruled out. mimocan have already made the rfs partition into ext2 and he didn't see any increase in performance.

iRS_ · Sep 27, 2010

i have a question, with this kernel i can use on sgs micro sd card formatted in EXT2 ?

thomas_d_j · Nov 29, 2010

woeds said:
Ok, so what filesystem does the internal SD use currently? Would it help if we change that to EXT4?

The /sdcard partition is apparently vfat:

Code:

# cat /etc/fstab
/dev/block/stl11 /cache auto llw,check=no,nosuid,nodev
/dev/block/mmcblk0p2 /data auto llw,check=no,nosuid,nodev
/dev/block/stl10 /dbdata auto llw,check=no,nosuid,nodev
/dev/block/stl9 /system auto llw,check=no
/dev/block/mmcblk0p1 /mnt/sdcard vfat rw
(null) /sd-ext auto rw

Code:

# mount
rootfs / rootfs ro,noatime 0 0
.
.
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:9 /mnt/sdcard/external_sd vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
.
.

I guess that (vfat) helps with compatibility for USB access, assuming it's a straight pass-through. But it's a pretty outdated filesystem and maybe that goes some way to explaining why my LOST.DIR folder is steadily filling up.

Even forgetting about speed, it would be nice if /sdcard could be a journaling filesystem like ext3. Anyone had a play with that?

Topics

Topics

[Dev Kernel] 2.6.29 Support for ext2/ext3/ext4/yaffs2

otrhodox

New member

Aweb

Member

ivanmmj

Retired Moderator

andars05

Senior Member

mekwall

Senior Member

andars05

Senior Member

mekwall

Senior Member

andars05

Senior Member

mekwall

Senior Member

nrg

Senior Member

mekwall

Senior Member

iRS_

Senior Member

thomas_d_j

Senior Member

Similar threads

New posts