Will journaled Ext4 kill my internal SD?
yuktsi said:
Will journaled Ext4 kill my internal SD?
Click to expand...
Click to collapse
Ummm...in a word, no.
Why would you think it would?
Sent from my GT-I9000 using XDA Premium App
Quick Answer: No.
Long Answer, Journaled filesystems like EXT4 have a "intent" log where they store the actions they are about to preform before they preform them, once the action is complete it is removed from the log. This is done so that if power is lost during an operation, the filesystem can "replay" the log (ie, go and check the last thing that was supposed to be done) and do it. This increases file system reliability at the cost of write speed (very slightly though) and causes more writes to your device.
That said, the increase in writes is very small and while it will wear your SD faster, we are talking about something like %1 faster which is no big deal.
Hope this helps.
edude03 said:
That said, the increase in writes is very small and while it will wear your SD faster, we are talking about something like %1 faster which is no big deal.
Click to expand...
Click to collapse
As to opposite to what? This interests me more. I thought that rfs has journaling too. So why would the journaling of the ext4 be wearing out the sd card more? Also why it should be slower in write as rfs then? (why would the system then when journaling with slower write speeds BE actually used as a "lagfix" and seen as a speed and smoothness improvement to the rfs?)
I have no idea about any of this, ask just for clarification and my laziness to google
Related
i tried doing some searching, but didnt find what i was looking for. my question is: which linux file system(ext2,ext3,ext4) is recommended for a partition on my sd card? is one better than the other? TY
EXT2 is a fairly simple filesystem. Great for data storage, i.e., data that doesn't change very often. EXT3 adds in JOURNALING to EXT2. This makes it good for data that *does* change often -- in the event of a bad unmount (power failure, crash, etc.), it is MUCH more resistant to corruption. EXT4 has some really neat new features that make it great for storing millions of files on ENORMOUS disks. None of the EXT4 features will make any appreciable difference on a 16GB flashdisk filesystem, performance wise. Delayed allocation though, could increase the risk of DATA LOSS.
Note that ext4 is supported on community android images mainly because it is "cool and new". It is therefore the general assumption that it must be "better". It isn't, really. I suggest going with ext2 or ext3. They each present benefits and drawbacks for this application, and it is YOUR CHOICE between them.
EXT2: advantage: no journaling -- makes your flash memory last longer.
EXT3: advantage: journaling -- resists filesystem corruption.
questions go in QnA not dev
This is the DEV Thread !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Could someone please inform me on what's the significance of having a linux swap partition on your SD? What is it and how do i do it?
and does compcache really help speed up the phone? i've heard that it actually makes it slower.
a response would be appreciated, thanks!
phillyboi47 said:
Could someone please inform me on what's the significance of having a linux swap partition on your SD? What is it and how do i do it?
and does compcache really help speed up the phone? i've heard that it actually makes it slower.
a response would be appreciated, thanks!
Click to expand...
Click to collapse
A linux-swap partition acts the same as a file swap would, becoming a place for the system to place cache for your apps. It helps speeds up app loading times by keeping them (and their components) in cache, even when not in use. Basically it expands the phones hardware RAM.
Compcache essentially expands your onboard RAM. The only tradeoff is that the extra space must be dynamically compressed/decompressed, which is considerably more taxing for the CPU.
I can't say out of experience that compcache actually slow down the phone substantially.
compcache w/ backingswap ftw. look into that. i've tried swap - its decent. i've tried compcache - hate it. compcache w/ backing swap? amazing!
Can't see that this has been asked already so I'll go ahead and be prepared to be flamed/ignored...
With apps2sd we don't seem to fill up our internal storage anymore so is it just being wasted? Would it have any benefit to use a bit of it for a swap file rather than have that going to the sdcard. I'm working on the assumption that the internal storage is faster than a class 6 but I may be wrong.
This is how we did it before everyone had swap partitions.. You can use a swap file on the internal memory but its slightly less efficient than a dedicated swap partition. There's really very little difference tbh.. Having the swap partition is just neater.
goldenarmZ said:
This is how we did it before everyone had swap partitions.. You can use a swap file on the internal memory but its slightly less efficient than a dedicated swap partition. There's really very little difference tbh.. Having the swap partition is just neater.
Click to expand...
Click to collapse
I see. Thanks for the reply. I find swap really bogs things down after a few days so I guess I'll continue to just use compcache (and wait for the desire to be released)
I did a search but couldn't find anything specific... so my question is, should I upgrade my ext3 to ext4? if so why? if not.. also why
gmelchert said:
I did a search but couldn't find anything specific... so my question is, should I upgrade my ext3 to ext4? if so why? if not.. also why
Click to expand...
Click to collapse
No. Most (all?) of the new 2.1 test build leak based ROMs do no support a2sd on ext4. On (most of) these same builds ext3 works automatically.
danknee said:
No. Most (all?) of the new 2.1 test build leak based ROMs do no support a2sd on ext4. On these same builds ext3 works automatically.
Click to expand...
Click to collapse
thanks thats good to know!
I know most of you are not Linux users so let me break this down for you:
EXT2: Very basic filesystem when it comes down to it -- think of it as a Unix filesystem you could place inbetween the likes of FAT32 and NTFS. I would nearly argue that this is the modern equivalent of FAT32 (which really really needs to die). We really shouldn't be using FAT32 but lack of native windows compatibility stops EXT2 from being a candidate for this usage.
EXT2 is highly recommended for your flash card. It won't over stress it and there aren't many alternatives that are better these days unless you're dealing with raw flash, which you'd then use something like YAFFS2 or JFFS2. The flash in compact flash cards is not raw flash.
EXT3: Picture EXT2 with a journal. It is backwards compatible with EXT2 (just doesn't read the journal).
A journal is NOT recommended for flash devices. (At least when the filesystem was not designed for raw flash and isn't tuned properly like YAFFS2 and JFFS2). Do you really want your phone to write all the metadata to the journal first and then to the filesystem? That's a ton of unnecessary I/O. If it has full journaling enabled you're writing all your data twice. This is not a good idea for your phone. This is one reason why NTFS has not become a standard for flash devices: Journals on flash are bad unless it's designed for flash from the ground up.
EXT4: same as EXT3 but is a copy-on-write FS with delayed allocation (holds data in memory longer before writing to disk to be more efficient / prevent fragmentation), increased number of files and size of files (more than a phone ever could need in our lifetime), etc. Some improvements across the board but not backwards compatible with EXT3 anymore if you're using the delayed allocation. Most likely to eat more memory on your phone.
This is completely unnecessary for a phone and really does not fit your needs. I don't understand why anyone would attempt to use this unless they simply thought "4 is bigger than 2 or 3 so it must be better!"
So there you have it. I may have forgotten a minor detail here or there, but this is the gist of it.
feld said:
I know most of you are not Linux users so let me break this down for you:
EXT2: Very basic filesystem when it comes down to it -- think of it as a Unix filesystem you could place inbetween the likes of FAT32 and NTFS. I would nearly argue that this is the modern equivalent of FAT32 (which really really needs to die). We really shouldn't be using FAT32 but lack of native windows compatibility stops EXT2 from being a candidate for this usage.
EXT2 is highly recommended for your flash card. It won't over stress it and there aren't many alternatives that are better these days unless you're dealing with raw flash, which you'd then use something like YAFFS2 or JFFS2. The flash in compact flash cards is not raw flash.
EXT3: Picture EXT2 with a journal. It is backwards compatible with EXT2 (just doesn't read the journal).
A journal is NOT recommended for flash devices. Do you really want your phone to write all the metadata to the journal first and then to the filesystem? That's a ton of unnecessary I/O. If it has full journaling enabled you're writing all your data twice. This is not a good idea for your phone. This is one reason why NTFS has not become a standard for flash devices.
EXT4: same as EXT3 but includes is a copy-on-write FS with delayed allocation (holds data in memory longer before writing to disk to be more efficient / prevent fragmentation), increased number of files and size of files (more than a phone ever could need in our lifetime), etc. Some improvements across the board but not backwards compatible with EXT3 anymore if you're using the delayed allocation.
This is completely unnecessary for a phone and really does not fit your needs. I don't understand why anyone would attempt to use this unless they simply thought "4 is bigger than 2 or 3 so it must be better!"
So there you have it. I may have forgotten a minor detail here or there, but this is the gist of it.
Click to expand...
Click to collapse
Nice explanation.
You left out the part about how apps load faster from RAM then they do from any sd card. The people running slower sd cards especially may potentially be experiencing a performance decrease due to a2sd.
I have abandoned a2sd because after I load every app that I use, (plus 10 random ones) I still have room left. Then I use the extra half a gig on my sd card for another 5 cds worth of music.
feld said:
I know most of you are not Linux users so let me break this down for you:
EXT2: Very basic filesystem when it comes down to it -- think of it as a Unix filesystem you could place inbetween the likes of FAT32 and NTFS. I would nearly argue that this is the modern equivalent of FAT32 (which really really needs to die). We really shouldn't be using FAT32 but lack of native windows compatibility stops EXT2 from being a candidate for this usage.
EXT2 is highly recommended for your flash card. It won't over stress it and there aren't many alternatives that are better these days unless you're dealing with raw flash, which you'd then use something like YAFFS2 or JFFS2. The flash in compact flash cards is not raw flash.
EXT3: Picture EXT2 with a journal. It is backwards compatible with EXT2 (just doesn't read the journal).
A journal is NOT recommended for flash devices. (At least when the filesystem was not designed for raw flash and isn't tuned properly like YAFFS2 and JFFS2). Do you really want your phone to write all the metadata to the journal first and then to the filesystem? That's a ton of unnecessary I/O. If it has full journaling enabled you're writing all your data twice. This is not a good idea for your phone. This is one reason why NTFS has not become a standard for flash devices: Journals on flash are bad unless it's designed for flash from the ground up.
EXT4: same as EXT3 but is a copy-on-write FS with delayed allocation (holds data in memory longer before writing to disk to be more efficient / prevent fragmentation), increased number of files and size of files (more than a phone ever could need in our lifetime), etc. Some improvements across the board but not backwards compatible with EXT3 anymore if you're using the delayed allocation. Most likely to eat more memory on your phone.
This is completely unnecessary for a phone and really does not fit your needs. I don't understand why anyone would attempt to use this unless they simply thought "4 is bigger than 2 or 3 so it must be better!"
So there you have it. I may have forgotten a minor detail here or there, but this is the gist of it.
Click to expand...
Click to collapse
I had never thought about this before. It makes a good point, flash memory dies after x ammount of Reads and Writes. Given it's mostly in the 100 millions, but it does more reading and writing than you would think it does, and you are effectivly killing the memory card twice as fast.
Good thing these things are relativly cheap.
this is all really good to know. thanks. i spent $100 on my sd card so maybe i should just foemat the whole thing to fat32.. (its class 10) while you guys are here, what exactly is the use of swap?
Sent from my HERO200 using the XDA mobile application powered by Tapatalk
gmelchert said:
this is all really good to know. thanks. i spent $100 on my sd card so maybe i should just foemat the whole thing to fat32.. (its class 10) while you guys are here, what exactly is the use of swap?
Sent from my HERO200 using the XDA mobile application powered by Tapatalk
Click to expand...
Click to collapse
SWAP = Page file in the Linux world. From what I have read (This may have changed since then) We don't have the ability to use Swap yet.
danknee said:
You left out the part about how apps load faster from RAM then they do from any sd card. The people running slower sd cards especially may potentially be experiencing a performance decrease due to a2sd.
Click to expand...
Click to collapse
You're right -- apps do load faster from RAM. However, when you're not using a2sd the applications are not on the phone in "RAM". They're in a flash chip inside the phone -- just like on your sd card. The performance should be nearly the same when you're using a2sd as it is when you're not using it.
The only reasons why a2sd should be slower are:
1) You have a cheap, slow SD card
2) The interface from the SD card to the phone is cheap and slower than the internal flash chip's interface. It was just a cheap design choice the manufacturer made.
3) The internal flash is simply faster from it being a better flash chip
feld is right. Using anything other than ext2 for the apps2sd partition boggles the mind. I have no idea why people insist on a: providing support for it and b: encouraging people to do it.
Ok, provide support for it for the people who know what they're doing/just want to do it for the hell of it, but having a journalled filesystem on an sd card makes no sense whatsoever.
As feld says ext4 uses up more RAM than ext2, which might be all well and good for things like the N1/Evo/Desire etc but not everyone has such a RAM beefy phone.
Besides that, the bottle neck in speed is the SD card/controller. No "faster filesystem" is going to improve that. Adding more IO is only going to slow things down.
Moved as not Android Development.
I'm interested in any real world experiences of people using a swap partition on the SD card or similar solutions. I mostly see guides about how you enable swap, which isn't that hard, but any quantifiable or subjective reports of improved performance is lacking.
My only experience using swap was using an openwrt router (with very limited resources) where it was vital for some stuff to function at all, but I couldn't see any general speed improvements, and when swap was used it was terribly slow.
Do you use swap or tried it, does it help? How much?
PremiumMediocre said:
Do you use swap or tried it, does it help? How much?
Click to expand...
Click to collapse
Apparently this is not something that interest people, but in case someone searches for swap and finds this post I can say it definitely helps with multitasking. Currently my phone uses over 100MB of swap space, and lags due to apps being terminated due to low memory is a more rare occurrence nowadays.
Just some interesting reading about this:
http://zerocredibility.wordpress.com/2009/08/24/why-android-swap-doesnt-make-sense/
http://android.stackexchange.com/questions/2310/how-will-a-swap-partition-file-affect-the-system
If you're still interested, read these two links. A bit old though, but the only difference might be that Google has put an effort into making Android's way of freeing memory better. In that case, from what they say, I'd say there's a chance that swap will increase your performance.
Thank you, I've been reading up on swap as well, and it's not completely clear cut.
From your first link the argument:
"Having swap actually prevents the native Android memory management scheme from activating. The system sees memory and doesn't distinguish between physical and virtual. It will therefore prefer swap over the native Android memory management scheme, and won’t activate the native scheme until swap is full."
I believe this is just plain inaccurate. Even if you set swappiness to 100 android will terminate apps without filling the swap space, and swap is never treated as plain ram as far as I know.
Some real benchmarks is sourly needed though.
PremiumMediocre said:
Thank you, I've been reading up on swap as well, and it's not completely clear cut.
From your first link the argument:
"Having swap actually prevents the native Android memory management scheme from activating. The system sees memory and doesn't distinguish between physical and virtual. It will therefore prefer swap over the native Android memory management scheme, and won’t activate the native scheme until swap is full."
I believe this is just plain inaccurate. Even if you set swappiness to 100 android will terminate apps without filling the swap space, and swap is never treated as plain ram as far as I know.
Some real benchmarks is sourly needed though.
Click to expand...
Click to collapse
I tried to find done benchmarks, but it seems like there are none...
And like I said, old links so Google might have done something about the issues they're talking about
Sent from my Incredible S using xda app-developers app
Also have a look in the desire Z section for this. They only have 512mb ram (we have 768) so they are always looking for ways to free up ram
There is a lot of discussion about swap so have a look there They might know a lot more compared with us
markj338 said:
Also have a look in the desire Z section for this. They only have 512mb ram (we have 768) so they are always looking for ways to free up ram
There is a lot of discussion about swap so have a look there They might know a lot more compared with us
Click to expand...
Click to collapse
I think the speed of the processor is also important in this context since the native way to save memory is letting programs recreate the last state they were in before they were shut down. A fast processor would make swap less attractive.
In case you anyone wants to try, I'm using the Hunterwu kernel and used swapper 2 to activate the swap partition. The only hang up setting it up was that swapper 2 identified the wrong partition as swap but that could be manually changed.
PremiumMediocre said:
I think the speed of the processor is also important in this context since the native way to save memory is letting programs recreate the last state they were in before they were shut down. A fast processor would make swap less attractive.
In case you anyone wants to try, I'm using the Hunterwu kernel and used swapper 2 to activate the swap partition. The only hang up setting it up was that swapper 2 identified the wrong partition as swap but that could be manually changed.
Click to expand...
Click to collapse
Tell us if its any better, I might do the same