yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] Smallsmx3:
Max warheads.....got to a windows xp computer now. trying to flash with odin....getting file analysis.....wont go past that. window also pops up saying autoplay and nothing happens. I get added com 6 when i plug in. worst day ever today
[Captivate Android Development] SlimJ87D:
I personally feel that it's also not worth using your internal storage for any fix. If there are damages done to it, you can't simply buy a new internal storage and replace it.
[Captivate Android Development] max_warheads:
Whether you use this fix, or no fix, you are using the internal flash partition. This isn't in /sdcard, the 14GB~ we can use, it's in the 2GB partition from the factory so how are we using it any differently?
[Captivate Android Development] Zilch25:
Don't get me wrong, I'm certainly not calling you crazy, I've followed the work you've done and I do respect your knowledge and opinions. I'd really love to see this I/O issue worked out, and I certainly don't see this as a permanent fix, but until the kernel modifications start to get refined this is what we're stuck with. Also I'll be the first one to report to this thread when/if my phone starts to crap up from corruption.
[Captivate Android Development] AJerman:
This doesn't even make sense. This is what I'm saying. You are doing the EXACT same thing as the other mods, just putting the file in a different place, and using ext2. I can assure you that you are seeing NO improvement over the ext3/4 on SD fixes. Like I said, being that the original author of this fix is suggesting that only dbdata be put on the image, this mod is the one, if either, that would make no real life difference.

The 3-4 second lag has NOTHING to do with an ext3/4 partition on the SD card, and everything to do with Samsung giving us bad source code or configs so that no custom kernel has been built without this problem. You can use ext3 with the stock kernel though, so if you don't want wake up lag, use ext3 with a stock kernel.
[Captivate Android Development] SlimJ87D:
Details about what this fix does:

Creates a VIRTUAL EXT2 filesystem inside the stock RFS filesystem on the internal SD card, with a 4KB block size. This means that this lag fix creates a buffer between the real filesystem and the android system. This buffer should reduce the amount of disk I/O required for all operations by utilizing EXT2 buffering, as well as not writing file access times to disk, etc. It allows only 1GB for application data at this stage, down from the 2GB of application data when running stock.

So you're saying that we aren't using any internal memory in any different kind of way? And we aren't risking damage to our internal storages?
[Captivate Android Development] Zilch25:
I never said the lag had anything to do with the SD card, it has to do with the kernel. It happens with all the mod kernels. I base my opinion on the fact that my phone completes the same tasks faster than it did either stock, or with the ext3/4 fixes, that's all. I know quadrant means nothing.

I actually agree that a kernel fix is the answer, but we aren't there yet. The debate over which FS to use and how it's going to instantly destroy your phone and kill your dog will continue until samsung finds some way to unsuck their FS choice.
[Captivate Android Development] max_warheads:
No, what I am saying is that the factory fresh stock rom is using the same space. This mod puts a buffer in place, and uses ext2 to do so. The phrase "internal sd card" might be causing this discussional discrepancy!

If Samsung had chosen an actually performant FS, we'd not being having these discussions anyways.
[Captivate Android Development] rajendra82:
Why there an added risk of corruption of the file system due to shutting the phone down? I am not sure that, I quite understand the issue. Is the RFS file that is mounted as the ext2 block device never fully written before the phone shuts off? If that is the case, why is the risk of corruption any less than having the same data written a individual files with the same file system.

Sorry about the newbie question ahead of time.
[Captivate Android Development] SlimJ87D:
Okay, well let me rephrase what I am trying to say. Authors have mentioned that these fixes which were done originally on External "SD Cards" could cause the SD cards life to shorten. The authors have also felt that it is not wise to use any means of "internal storage" for any kind of fixes because of the possibility of corrupting, damaging to wearing down your own internal storage.

For this fix and method, it uses your internal storage to do the fix. For this reason, I feel that it's a risky fix. I just want to warn people of the "potential" problems this fix may cause.
[Captivate Android Development] max_warheads:
I'll give you that one. After all, we're changing something away from the way the manufacturer made it, thus ....

There are risks involved in any mod and admittedly there are people that will apply this without blinking an eyelash. But then, 90% of those wouldn't read the warnings anyways.

Ooh and it's why I didn't buy an iPhone. (no offense meant, just statement of preference for android)
[Captivate Android Development] Zilch25:
Just so you guys know, I've edited the OP with the cons. People should be aware of what they are/could be getting themselves into should any of these concerns turn out to be accurate.
[Captivate Android Development] AJerman:
Well, and that's it's own argument too. Honestly, I'm probably never going to take out my SD card, so why not use that since it can be replaced. I agree. However, I still would like to see ANYONE show me a phone that has stopped working because they used a journaling file system on flash storage. Like I said, I'm not really that worried about actually wearing out flash storage, but if you are, the SD card can be used and replaced if there is ever an issue.

My point to you was that ext3 is enabled by default in the stock kernel, so you dont NEED to use ext2. This mod using ext3 wouldn't be that bad (again, unless you're worried about wear on the internal memory, but then you can do ext3 on external, like we've already done, and still not have wake up lag). What I'm talking about is just ext2 vs, lets just say ext3 only since it's all that's in the stock kernel. ext2 is just a bad, bad idea. Why would you use a file system that you KNOW is going to become corrupt over time?

Beacuse ext2 is a non-journaling file system that relys on fsck to do a check on the file system after an unclean dismount. Android however, never cleaning dismounts anything but the sdcard partition, AND doesn't include fsck to fix any problems. Other file systems like ext3 and ext4 are journaling file systems which rebuild themselves automatically based of their journal file, even if there was an unclean dismount.

Now, you can assume that most of the important writes are out of the way when shutting down, so even the unclean dismount may be somewhat less harmful, but it's still there, and when you have a loss of power due to a hard reset, battery pull, crash, whatever, you can plan on losing data for sure with ext2.

Anyway, I've voiced my opinion. I'm not here to argue with you guys, and I'm certainly not here to tell anyone that their mods are bad mods. Hell, I wrote an overclocked kernel. That definitely leaves room for argument over if it's a good idea or if it will damage the hardware. I just see too many new people using this phone without knowledge of what these mods are doing other than giving them a fast Quadrant score, and I wanted to reiterate my concern over the ext2 file system, especially with the data stored in these particular partitions. Zilch updated the original post with warnings, and that's all I can ask. :)
[Captivate Android Development] NukaCola:
Agree.

I have only skimmed the thread just now (ok, the last couple of pages). If you don't value your data and/or want random app force closes, go ahead and use this method. I actually considered mounting a partition ext3 off the internal sd but rejected it as an uggly solution. Mounting ext2 on a loop device is just asking for issues. Android does not unmount your filesystems, they get an unclean shutdown *every time*. ext2 doesn't have any kind of resilience against that kind of usage. An ext2 filesystem that is unmounted cleanly every time is still 'supposed' to be fsck'ed every N mounts! e2fsck does a LOT of work that you need to maintain your filesystem properly.
[Captivate Android Development] ranova:
except for me, and MANY other people, those external SD ext3/4 hacks do not improve actual world usage. Sure, it may bump your quadrant scores up, but everything else lags as if it were stock.

there have been only a few people who vouch for the speed increase of the ext3/4 hacks through a few application tests, and I am weary of every new method that comes out. I'll stick with the NAND hack, for now, as it works for me (but limited to 130mb app space).

I'm content with my 850 quadrant score, but everything else flies.
[Captivate Android Development] Zilch25:
I hear you loud and clear, and I do agree with you, though I'm still a bit leery about the journaling wear. The other reason I'm using ext2? I didn't write the mod, though I do think I'll goof around with it and see what I can come up with. I dont mind sacrificing an arbitrary benchmark for a more reliable experience.
[Captivate Android Development] NikAmi:
I think that if you want to unmount and sync the SD card during a shutdown, you just have to add the commands to the source file with the shutdown events. I have been looking at the code for the past hour, but I can't find the exact file and I need to get back to studying. From my newbie look, I thought that maybe a modification of the ipmi_poweroff.c file might work.
[Captivate Android Development] AJerman:
And that's certainly an option too. I'm sure that could be added to the kernel code, but then we're back to the wake lag until we fix that, haha. You still have the issue with hard reboots, battery pulls, etc, but at least the system would unmount properly.
[Captivate Android Development] NukaCola:
Exactly, what is the point of hacking workarounds to support this hack into the kernel when clean(er) methods exist there?
[Captivate Android Development] flashman2002:
Wow, scored 2133. Other lag fix I hit around 970. Time to try out the browser and market compared to my wife's phone.

NOTE: I used busybox 1.16.1 or something like that and it went through. Wasn't going to read all 22 pages to see if that was mentioned.

Holy crap, those who think quadrant numbers don't mean anything should take a second look. My Dolphin HD browser opened immediately, it took my wife's Captivate 30 sec longer just to open the browser. Her phone is factory stock.
[Captivate Android Development] ranova:
we are only saying that because people were skeptical after the other hacks that required the SD card, which had huge numbers in Quadrant but very little improvement (if any) to real world usage. Dolphin HD factory is unusable on factory SGS's, and was unusable (for me) using the ext3/4 hacks.
[Captivate Android Development] larry996:
Sweet mod, starting from scratch Odin Restore:

-Rooted

-Rom Manager

-1.2 Ghz Kernel

-EXT2 Lagfix

=2502 Quadrant Score!
[Captivate Android Development] Zilch25:
Okay, I've been thinking about this a bit, and I'd love to hear the opinions of AJ and Nuka and other knowledgeable individuals.

If you guys haven't given this a whirl and messed with it a bit, which I'm assuming you haven't due to the EXT2 instability issue (which is understandable) then you're going to have to take our word for it as folks who have been running this sucker with both stock roms, custom roms, and other fixes (including kernel mods). Just give us the benefit of the doubt for this one.

Assume for a moment that we aren't suffering a mass delusion and that our phones REALLY are snappier, loading things faster, and generally running amazingly.

Lets shift gears into WHY that might be. Is it due to the lack of journaling? I know that slows things down, but that drastically? Is it due to the fact that the data is all contained in internal memory and as such just has higher throughput? Is it possible that there is another way to approach this problem and is there perhaps something to be learned through this?

I think everyone reading this forum right now is looking for the next big thing that will turn these devices into the gadgets we KNOW they can be, and I'd love it if we could find a way to pool these different approaches in such a way that we can do away with the potentially awful side effects.
[Captivate Android Development] brandonb81:
Wow! Huge real world difference in how the phone runs. Such an easy fix! Thank you so much!
[Captivate Android Development] max_warheads:
Stupid question: what about adding e2fsck to the userinit before mounting?

I'm going to look into this myself over the next hour or so.
[Captivate Android Development] shep211:
Can you or anyone post a link to the 1.2 ghz kernel please. I checked the 1.2ghz thread but didn't find any linked kernels.
[Captivate Android Development] cropythy:
I don't have the link (sorry) but it was around page 7 or 8, but personally don't see the point since there still is wakeup lag and the captivate now flies with this fix without overclocking for now.
[Captivate Android Development] shep211:
Thanx I found it.
[Captivate Android Development] AJerman:
What I don't understand is that I have felt a very definite real world difference with the mods I had already done. There's zero question in my mind that putting the data partition on SD with either ext3 or 4 made my phone much snappier than before. It was very noticeable on startup from the time you saw the home screen until the time the system was actually usable.

Now, I would say that both ext2's lack of journaling and the fact that you're on internal memory would make this mod faster, however, how much faster is nearly impossible to test. The reason the SGS phones are getting the high Quadrant score with these mods is strictly because of the file system score it's getting. I don't think the Quadrant test is a proper test for this because the read and write speed tests of the disk take less than a second to complete both, meaning it' probably doesn't have anywhere near an accurate number. I could be wrong, but I don't see how you could benchmark a file system that quickly. The DB read write speeds are increased, but that's on a benchmark which is likely writing a ton of data to the db, then reading a ton of data from the db, neither of which you do in that type of manner very often in your daily use.

I don't know. It's too hard to say for me. Obviously any of these mods has given us an improvement over the stock file system, but I think we've gotten faster than Quadrant can reliably measure and are sort of cheating the system. Our 2500 score phones aren't THAT much faster than other phones, because we only get that score based off of a ridiculous file system score. Someone posted a screenshot of Quadrant Pro earlier and you could see how much higher CPU speed 2.2 gave the N1. That's the kind of thing that can make a difference in every day use. You can only write your files so fast before you have to wait on other things to finish, like CPU processing, or memory read/writes, etc.

But you're right, I haven't actually done this mod yet to see the difference. You all say you're seeing a speed difference, but I say I saw that speed difference before with my ext3/4 on SD. Maybe when I get some free time I'll try this mod and see first hand what it's like. Until then I can't really compare it myself. I guess the biggest thing is that I, personally, don't think ext2 is worth the speed increase regardless of how much faster it is. I'd like to try an ext4 partition in a similar manner and see how it does comparatively to see if it feels like it's more the internal SD speeding it up, or just ext2.
[Captivate Android Development] Zilch25:
I actually saw the same screencap with Quadrant pro, the IO made up 90% of the score for the SGS, which obviously can't be accurate. I really do think there is something to this approach but you're certainly correct in being cautious using EXT2, I'd love to see an EXT4 version of this if for no other reason but to see if the performance is still there (within reason) while still maintaining data integrity. I guess I'd like for us to all have our cake and eat it too.

I'm actually working on throwing the EXT4 hack back onto my phone again as we speak just to run some comparison tests between the two- I've got to admit the wakeup lag is really upsetting though, hopefully Mimocan will give us some good advise- he actually just fixed that SAME issue for the guy who does the Samset ROM.
[Captivate Android Development] ranova:
AJ, you should also try out the NAND hack.

By going from stock to only testing/using one method, you cannot give a good enough assessment that it is indeed faster. I've tried out every method except this method, as I do not have time to tinker with my phone tonight.

So far, the NAND hack has given me the best real world performance, but the worst Quadrant scores (a little higher than stock).
[Captivate Android Development] Bjd223:
I am not sure how Flash is implemented in phones, but I know a few things about SSD flash devices, etc. If the system has any wear leveling or Garbage Collection running then you don't have to worry about where the writes are going (like on a journaled FS where the journal itself gets hammered over and over). The flash controller will dynamically put the data where ever it wants (to extend working life) not where you tell it. It also does not care about partitions or the file system(s) on the drive. The flash is managed by the controller and then the controller creates a virtual disk that the OS has access to, and then partitions are placed on top of that.

The only thing you really need to worry about is the amount of data written and the average write amplification. If you make a ton of small writes your write amplification will be through the roof, if you make decent size writes then write amplification is low. Caching and write combinig has a huge deal to do with this, but either way the controller will manage where this data goes automagically. The less you write the longer your drive will last, obviously. However with write amplification a very small write could yeild a very large write to the media.

Also as Flash become 'dirty' performance will decrease as writes require an extra operation to be completed. So running endless benchmarks are only going to kill your performance sooner, so please just keep this in mind. Typically controllers will send writes to clean Flash first but once that runs out they have to make sure the cell is actually empty. When you delete something on Flash media the electrons are not flushed, the virtual file system on the controller is updated saying it is deleted but really nothing happens (this is the reason for ATA-TRIM command).

Anyway I can talk about this non-sense all day, and if you are going to replace the FS on the phone you might as well pick one designed for Flash, as the overhead will be much lower and the writes will be as minimal as needed to get the job done.

http://en.wikipedia.org/wiki/List_o...imized_for_flash_memory_.2F_solid_state_media

Linux supports a few nice Flash file systems that could be implemented.

P.S. If anyone makes a mod replacing the stock file systems please (try to) make sure your partition(s) are aligned correctly to the erase block size of the Flash chip(s) used.

Sorry for the long post.
[Captivate Android Development] NukaCola:
I don't doubt it is fast. However, I and many others do notice the a2sd fix is faster in real life as well, something there are still people that dispute.

I think it is both. I did consider using (well testing) ext2 xip, but I figured we'd have way to many issues with unclean shutdowns.

I think all the activity htat is going on now is great! I get home from work and there are new whole threads and fixes all over the place, there is no way for me to keep up at the moment. Give it just a little bit of time and I think we'll figure out the best performance/reliability compromise.

If the sleep-lag issue was fixed we could start using proper fixes. I have stared myself blind at that (not to mention the number of boot-loop test kernels I now have). I need a little more time off before I look at it again ;)
[Captivate Android Development] Zilch25:
Keep up the good work Nuka, I'm sure that kernel hacks are going to end up being the way to go for performance increases rather than all these roundabout methods. Hopefully we get our wakeup lag miracle soon haha.

I suppose having all these methods explored will probably result in us getting the best of both worlds, hopefully the outrageous performance we want, and some peace of mind that our devices aren't going to melt into a $500 puddle in our pockets :o
[Captivate Android Development] novaIS350:
Since I've applied this fix several apps have started crashing consistetnly. I've since reverted back. Ill let you know if all is back to normal
[Captivate Android Development] golemaw:
Update: I notice my dtunes music lock screen controls no longer work as it should. When waking up the phone from sleep I expect the music controls instead of the lock screen... Now it just brings up the lock screen and after unlocking the music controls show up.
[Captivate Android Development] apb7419:
Hey Guys I am pretty new on this web site and following all of the post and hacks and this hack as well. I was playing aroung with these hacks including this one and applied them in a certian order.. so this is what I did and let me know if this is the best way of doing this.

1st: when back to complete stock rom flashed with Odin one click flash to get a fresh start. Also when and flash the stock ROM .. may have been redundant but did it anyways.

2nd: Rooted phone, installed Busybox 1.17.1 and applied this lag fix.

3rd for the fun of the hack installed the 1.2 OC over top of this lagfix.

4th killed apps with ATK..

ran Quadrant and scored 2550 see below

Going to run this for a while and see if it is stable..
[Captivate Android Development] abezapata:
WOW!!! This fix really does improve real world use. I previously had the mimocan fix on my captivate and I can happily say this fix surpasses the mimocan fix in real world use. Now all this nonsense about using ext2 on the internal sd card is in the back of my head and now I want to remove it, but after checking to see if I would even notice a difference, I am reluctant to remove this fix. It simply is amazing.

No lag when waking the phone from sleep, apps open quickly, and the list goes on. Screw Quadrant as programs like that are designed to make users happy they have a "powerful" phone according to it. I do not care about numbers and this fix honestly makes this phone a lot better.

Now does anybody suggest I try the ext4 fix to compare my findings as I am still concerned for the safety of my internal sd card. A link would be helpful.

Thanks for reading guys and for the help. This forum is awesome.
[Captivate Android Development] mykenyc:
can't your just ask the to have a ext3 or ext4 version.
[Captivate Android Development] dontshakepandas:
Tried it, got high quadrant scores, but the real world performance didn't feel as quick as the NAND hack to me so I went back. I have to admit, the chance of permanently damaging my phone made me a little uneasy about it anyways.
[Captivate Android Development] Baccarat:
Benchmarked with Quadrant Advanced

I benchmarked this fix against a clean stock stock ROM and the detailed results are below with the difference in parenthesis. As you can see, Quadrant is showing an almost 900% increase in I/O which is solely responsible for the 143% increase in overall score. Clearly this is impossible in the real-world.

Many people have reported real-world performance improvements using this fix, but Quadrant obviously cannot be used to measure it.

Total: 2142 (+143%)

CPU: 736 (-1%)

Mem: 1787 (+1%)

I/O: 6988 (+898%)

2D: 306 (+3%)

3D: 893 (0%)