[Epic 4G Android Development] mystica555:
My friend has since reverted to 1ghz. Having e2fsck however would have prevented a majority if not nearly every one of his reflashes.

I knew its overheating, and told him this. I've done plenty of overclocking on my Q6600 as well and am quite familiar with over-heat / lack-of-power conditions which cause instability and shutdown/reboot.

It is also not the core problem. It's best practices to make random small issues (a reboot) as minimal of a failure point as possible.

Having an entire filesystem go wonky when your phone thinks it's written a lot of stuff and suddenly reboots, can screw up the running system on the phone, which makes the user angry and annoyed that after a simple unexpected reboot a reflash must be performed.

I've been a PC enthusiast since I was 7. Now nearly 21 years beyond then, with everything I taught myself to learn more about what I am using, extending the hardware and software t to its full potential and then exercising this knowledge daily at home and on the job, has given me a pretty good idea of what works and what doesn't.

I try to recommend things (such as a filesystem check upon reboot to fix errors from an unclean unmount) that benefit *everyone*.

Granted, the bash and /etc/profile were enthusiast requests; e2fsck however is nearly a survival requirement a filesystem that has a ram cache on a device which can have random power loss. Desktop, phone, mission critical server, it doesn't matter.

There is much talk on many forums/IRC channels about ext4 being potentially unsafe with current harddrives with massive caches and random power loss. These issues have been around in the kernel for a while regarding 'barriers' which are supposed to set checkpoints in writing between the transaction journal and its commit record. Again due to large caches, even if the order is maintained, the records could be written backwards. A barrier is meant to force the drive to make certain writes are properly sequential and only unblock when they properly complete.

If this gets out of order, your filesystem is toasted. How toasty, is all up to chance.

There is even more talk about RAIDs which basically *must* be put into SYNC write mode as they can and will totally screw up if certain transactions are lost. Your entire array could be kaput because of a non-battery-backed-cache. This is the 'mission critical' option: RAID with a SYNC mounted filesystem.

Well, its nice to have a fancy firmware on a phone that works faster than stock, has a lot less crap, but if it is also more unstable simply because of an oversight, I call this a serious mistake and it should be fixed.

And then everyone coming and saying "well its supposed to be that way" .. I honestly wonder if *you* understand the potential risks of running without a filesystem repair tool. If you run Windows, OSX, Linux on the desktop, BSD, ANY useful operating system nowadays, has a filesystem repair tool...

DOS came with chkdsk. It's been known since the dawn of computing that storage can fail randomly.

Believe me: errors can, and *will* happen. How often is irrelevant. Having a filesystem repair tool, e2fsck in this case, is always a good thing.