[Q] IS ext4 conversion truly GOOD? - Galaxy Tab Q&A, Help & Troubleshooting

Having read extensively, the following thread got my interest:
http://forum.xda-developers.com/showthread.php?t=800353&page=10
and this,
http://en.wikipedia.org/wiki/Comparison_of_file_systems
The question is, does converting the filesystem via custom kernels from RFS or native samsung filesystem to ext4 worthy enough? Reading the above debate, the opinions are subjective lacking truly reproducible results!
My point is can the lame limitation of 4Gb in current filesystem be overcome by ext4 conversion(offered by custom kernels) or does it stay same?This really cripples the true hD experience this device can offer! As the gingerbread (nexus s) runs on the ext4 by default than will the "expected upgrade" unlock the 4gb file size limit of RFS to ext4 almost unlimited(16 GB) file size?
Please share thoughts!

Related

EXT Filesystems

Okay so when we first had apps to SD, we used an extended partition called EXT2. And then cyanogen and all the other devs decided that ext2 wasn't as good as ext3. Now I realize that there's an ext4. So my question is, is there an infinite list of ext filesystems and is it a coincidence that ext2<ext3<ext4?
The question relies on a bit of history.
ext - (extended file system) which was a file system used in minix and *nix.
ext2 (second extended file system) was a replacement for ext. Primarily this allowed for larger files and longer file names.
ext3 was the replacement for ext2... intuitively enough. the most important thing it added was journaling. There were quite a few other changes but the journal is the reason ext3 is favored for the G1. The short version is that an journaled file system is less likely to become corrupt if not powered off correctly.
ext4 extends ext3. From a G1 perspective the main things it provides is some performance improvements as well as journal checksumming. There are quite a few other changes but most will not be pertinent to an embedded environment. Check wikipedia if you want a complete list.
Ext2 to ext3 is completely backwards compatible - if you make a partition ext3 you can still mount it as ext2, you just lose the journal capability while doing so.
Ext3 to ext4 is not backwards compatible if extents are used. Truthfully, unless you map extents to a smaller multiple of block size of your flash card using extents on an SDHC would probably not be advisable. People enable it with the default 128MB extent size and 4KB block size none the less. It would be a long discussion as to why this is non optimal considering a flash block size of 128KB (page size 64KB I believe) but it is not worth having.... most people enable it and so ext4 in most cases will not be backwards compatible.
EDIT: As of this moment there is not an EXT5 on the horizon. Most next gen file system work on Linux is concentrating on BTRFS and a few others whose names escape me.
EDIT2: added block size to EXT4 extents to be clearer.
JanetPanic said:
The question relies on a bit of history.
ext - (extended file system) which was a file system used in minix and *nix.
ext2 (second extended file system) was a replacement for ext. Primarily this allowed for larger files and longer file names.
ext3 was the replacement for ext2... intuitively enough. the most important thing it added was journaling. There were quite a few other changes but the journal is the reason ext3 is favored for the G1. The short version is that an journaled file system is less likely to become corrupt if not powered off correctly.
ext4 extends ext3. From a G1 perspective the main things it provides is some performance improvements as well as journal checksumming. There are quite a few other changes but most will not be pertinent to an embedded environment. Check wikipedia if you want a complete list.
Ext2 to ext3 is completely backwards compatible - if you make a partition ext3 you can still mount it as ext2, you just lose the journal capability while doing so.
Ext3 to ext4 is not backwards compatible if extents are used. Truthfully, unless you map extents to a smaller multiple of block size of your flash card using extents on an SDHC would probably not be advisable. People enable it with the default 128MB extent size and 4KB page size none the less. It would be a long discussion as to why this is non optimal considering a flash block size of 128KB (page size 64KB I believe) but it is not worth having.... most people enable it and so ext4 in most cases will not be backwards compatible.
EDIT: As of this moment there is not an EXT5 on the horizon. Most next gen file system work on Linux is concentrating on BTRFS and a few others whose names escape me.
EDIT2: added page size to EXT4 extents to be clearer.
Click to expand...
Click to collapse
oo Awesome, THanks for the response. Cleared things up. Another thing...why didn't developers start with EXT4 then?
Ext4 support wasn't built into Android - Cyanogen (I think, don't mean to step on anyone's toes) added it in. And it is still a pretty new file system type, so after patching in support, Cyanogen still had to go back and bring in some newer patches to try and fix bugs.. It's very cutting edge still. Given time, it'll be the "standard" and we'll be poking at some other new file system and wondering why everyone doesn't use it.
The original kernel for android would not have supported ext4, since it was not available at the time of the G1 release.
I am going from memory but I think the cupcake release used a 2.6.27 kernel. This would have been before ext4 support was released for general consumption, though it might have been available under experimental.
Cyanogen and most of the custom ROMS out there are using a 2.6.29 kernel now, which has a general release of ext4. There are some known problems with the stock ext4 release in 29 but Cyanogen backported the fixes from 2.6.30. Since I believe most of the ROMS are "Cyanogized" you should be fine now with any of the current ROMS on a 29 kernel that supports ext4, which is not necessarily all of them. I pretty much stick to Cyanogen's ROMs so I can not say what the others do and do not have.
Saiboogu said:
Ext4 support wasn't built into Android - Cyanogen (I think, don't mean to step on anyone's toes) added it in. And it is still a pretty new file system type, so after patching in support, Cyanogen still had to go back and bring in some newer patches to try and fix bugs.. It's very cutting edge still. Given time, it'll be the "standard" and we'll be poking at some other new file system and wondering why everyone doesn't use it.
Click to expand...
Click to collapse
JanetPanic said:
The original kernel for android would not have supported ext4, since it was not available at the time of the G1 release.
I am going from memory but I think the cupcake release used a 2.6.27 kernel. This would have been before ext4 support was released for general consumption, though it might have been available under experimental.
Cyanogen and most of the custom ROMS out there are using a 2.6.29 kernel now, which has a general release of ext4. There are some known problems with the stock ext4 release in 29 but Cyanogen backported the fixes from 2.6.30. Since I believe most of the ROMS are "Cyanogized" you should be fine now with any of the current ROMS on a 29 kernel that supports ext4, which is not necessarily all of them. I pretty much stick to Cyanogen's ROMs so I can not say what the others do and do not have.
Click to expand...
Click to collapse
Ah Thank-you both of you. Cleared things up alot
This explains it nicely! Ext4 for cyan. Is it still a good idea to run the linux swap partition as well with ext4 and Cyan roms?
yes
you still want to run a linux-swap partion, swap and ext are 2 different things. Swap is where your system extends it's operating memory not storage as to say even a full computer linux distro uses a swap partion<I know my ububtu does> so yes if you want the benefits of swap than you better have a partion for it
Awesome..
Thanks to alritewhadeva for rising this question and thanks much to Saiboogu and JanetPanic for letting us win users what exactly these are for. Couldn't find better explanation even after googling about them.
gridlock32404 said:
you still want to run a linux-swap partion, swap and ext are 2 different things. Swap is where your system extends it's operating memory not storage as to say even a full computer linux distro uses a swap partion<I know my ububtu does> so yes if you want the benefits of swap than you better have a partion for it
Click to expand...
Click to collapse
Regarding this linux-swap.... I do have 32MB partition for that one created before installing the ROM. Now, are cyanogen's roms take advantage of this partition automatically or do I need to "enable" or change setting for that to happen?
If you read the first post on cyan's rom, I believe it does but as compcache, which I believe and I might not be right but I think it is just a better way of swap, I think more efficent
I repartitioned today to ext4. I used cyan's userint.sh and Mike Taylors user.conf. I'm not convinced it is working right at it seems more sluggish at times.
I just use a 96mb linux swap myself that I turn on with swapper and it is quite snappy, there was a thread were people were saying that comp wasn't as good as swap so I decided doing all that was just a hassle so I stuck with tried and true swap
This is the MT user.conf and the one I'm running.
# User.conf by miketaylor00
# General parameters
general{
apps2sd=0 # this is useless here, require a modified a2sd script
media2sd=1 # moves the medias to sd if /system/sd/media exists
}
#compcache related parameters
compcache{
compcache_en=1 # enable(1) or disable(0) compcache
cc_disksize=32 # Ram swap disksize - any number between 1 to 95 should work
cc_memlimit=18 # Limite the memory usage when backing swap is used
cc_backingswap_en=1 # enable or disable backing swap
cc_backingswap=/dev/block/mmcblk0p3 # pointing to the backingswap partition device
cc_swappiness=28 # default 60
}
#Linux swap parameters
#
# linux swap can only be enabled if cc_backingswap_en is set to "0"
#
linux_swap{
linux_swap_en=0 # enable(1) or disable(0) linux swap
linux_swap_partition=/dev/block/mmcblk0p3 # swap partition device
swappiness=30 # default 60
}
#virtual memory
sys_vm{
sys_vm_en=1 #enable(1) or disable(0) virtual memory configurations
page_cluster=3 # default 0
laptop_mode=0 # default 0
dirty_expire_centisecs=3000 # default 3000
dirty_writeback_centisecs=500 # default 500
dirty_background_ratio=5 # default 5
dirty_ratio=10 # default 10
}
#cpu clock
proc_cpu{
proc_cpu_en=1 #enable(1) or disable(0) user cpu configurations
# freqency options
# 19200
# 122880
# 128000
# 245760
# 384000
# 528000
scaling_min_freq=192000 # default 245760
scaling_max_freq=528000 # default 528000
sampling_rate=2000000 #default 200000 depending on kernel version
powersave_bias=0 # default 0, CM3.9.6 default uses 200
up_threshold=45 # default 40, percent cpu usage before going up a speed step
}
gridlock32404 said:
If you read the first post on cyan's rom, I believe it does but as compcache, which I believe and I might not be right but I think it is just a better way of swap, I think more efficent
Click to expand...
Click to collapse
Compcache is different to swap.
Swap is a virtual extension of the RAM, which is why it gives us a performance increase. Although adding x amount of swap space isn't the same as adding x amount of RAM.
Compcache compresses what's in RAM, which in theory increases the amount of RAM
Compressing pages and keeping them in RAM virtually increases its capacity. This allows more applications to fit in given amount of memory.
Click to expand...
Click to collapse
I flashed to Cyan's lastest this morning. I assume that user.conf and userint.sh was replaced with Cyans own?
I'm super fuzzy on all this, as I will be running Cyan's roms from now on, I just need a system/setup/ext that's optimized for his roms. I didn't have much luck with MT's for whatever reason. It ran, just lagged.

[Q] Ext4 System partition on N1

I've been looking through the forum and the Samsung Galaxy apparently have something call a "lag fix" which change the system partition to ext4 (correct me if I'm wrong). This leads to my thinking what is our N1 system partition? And can we change to Ext4 if it is not already is? Or does the N1 support ext4 at all?
Using CM7 w/ CM7 kernel, no DT A2SD for the moment.
AFAIK, it's EFS, and there's absolutely no need to change it. On SGS it's a matter of necessity, awkward solution to a bad problem that Nexus doesn't have.
Thanks, it's great to know our phone is still the best!

[Q] no ext3 in froyo 2.2?

Hi all,
I got my galaxy i9000 (froyo.bujp7 - v2.2 ?, kernel 2.6.32) since three weeks and as I'm exploring its abilities I came to wonder whether it's really missing an ext3 support?
The only reason why I need this file system is because I have a file which is greater than 4 GB in its size (it's a map file for navit). So as FAT32 won't be able to address such large files, I formatted my external SD as ext3 on my PC (Debian Squeece, kernel 2.6.34.1 - preemptive).
I was expecting it to work out of the box, since ext* is a native linux file system.
I browsed the net and all I got was some tutorials for app2sd and such. From what I think I've understood, I need a different ROM that supports ext3, is that correct?
I actually like to use the phone for a while before I start hacking its guts. But in case I really have to go through this, can anyone give me a hint where to start?
Thanks in advance.
gilzad
Many of the custom kernels here have support for ext4 included as part of their lagfix schemes, e.g hardcores or voodoo kernels. Unfortunately, as far as i know the sd cards are always mounted with vfat instead of autodetect so you might have to manualy set that in the corresponding mount file.
Hope that helps.
Sent from my GT-I9000 using Tapatalk

[Q] Lagfix Question

What is the disadvantages of No-RFS Overkill?
Why does some people avoid using it?
tanjiajun_34 said:
What is the disadvantages of No-RFS Overkill?
Why does some people avoid using it?
Click to expand...
Click to collapse
after some time you might encounter a corrupt file system.
It's only useful for high quadrant scores anyway, so I advise to avoid it. IMHO ext4 ext4nj ext4 is really fast enough
If you want to use it anyway keep backups, and keep not only the latest.
What about ext2?
Why do people use Ext4 instead now?
tanjiajun_34 said:
What about ext2?
Why do people use Ext4 instead now?
Click to expand...
Click to collapse
there's a endless thread discussing exactly this in the Development section
my summary:
ext2 has no journaling and is therefore prone to corruption. But since no one heard of one case where ext2 corrupted it's save to assume that it's not too dangerous.
ext2 also gives you higher quadrant scores but in normal use you won't feel a difference to ext4.
The difference in power usage is ridiculously slim, it's probably not even there.
I recommend ext4, but try out ext2 if you want to, if you feel an improvement keep it
Regular backups are wise regardless of your file system (that applies to everybody: )
tanjiajun_34 said:
What about ext2?
Why do people use Ext4 instead now?
Click to expand...
Click to collapse
Ext4 is newer.
ext2-ext3-ext4
linux makes new file systems and makes them better and better.
But the difference wont be that big

MTD & Non MTD

Can somebody explain what is MTD, and non MTD.. Something that normal beings can understand..
Sent from my GT-P1000 using XDA
Sure, here you go, a nice story for all humans to understand :-D
Think about Windows 95 which was running on the Fat32 filesystem. Back then files rarely reached 2GB in size and hard drives were really small. Later came Windows 7, for example. Windows 7 uses NTFS, which is also a filesystem but adapted to be more suited to the times of today. We now have DVD images which regularly exceed 2GB, so the Fat32 filesystem would be pretty useless today.
MTD is like NTFS and BML is like Fat32. Like Windows 95 can't run on NTFS, so Gingerbread cannot run on MTD. As Windows 7 runs crappy on Fat32, so does ICS run worse on BML than MTD.
MTD means storing data in a completely different and more flexible way. This is why it is better to use it.
To understand why you can go from BML to MTD and not the other way around here you go:
MTD is newer and smarter. Therefore, it can take BML into account and convert it correctly as it can understand it. BML on the other hand is older and MTD did not exist back then. Therefore BML cannot convert MTD back.
Now, when you need to change MTD partition sizes, you have to erase everything. Resizing partitions complicates things because there is a high risk of corrupting data in the process. Normally you would need special tools to resize partitions (even on your PC you need special tools). Also, the partition type must support resizing. So, to avoid complications, it is safer, faster and simpler for everyone to just erase everything and start fresh because this way we have a higher degree of control. That means less chances to brick the device and unfortunately a lot of data restores if you want to run the latest and greatest versions of Android.
I hope this sheds some light on the MTD matter to everyone and why some things are impossible as well as why some requirements must be met.
Peace,
C.
Wow that counts a million thanks m8.. But I could just click one in here.. This explains why everybody running behind MTD now...
Thank you superbeing...lol
Sent from my GT-P1000 using XDA
how can i find out which one is mne?
do u know any way to find out what type is it?
king-heart said:
how can i find out which one is mne?
do u know any way to find out what type is it?
Click to expand...
Click to collapse
usually cyanogenmod 9 & 10 are mtd. older versions are bml

Categories

Resources