Filesystem Corruption?

Question

Hi, Folks,
While this is indeed conjecture, it appears that the 2.0 series of firmware has a filesystem corruption problem as the amount of content on the device increases - in particular, once many applications have been installed. The behavior that I've witnessed in this circumstance is somewhat progressive. Initially, application install or updates begin to slow down dramatically. User behavior starts to contribute to the problem: when an update might takes more than five minute, folks may try aborting the update or sync, which often leads to a corrupted filesystem. This is easy to identify; powering down then back up again will lead to an "Apple logo" hang. Only a DFU restore will recover from this failure.
Much more significant is that even in the absence of inappropriate user behavior, the filesystem issue continues to worsen over time. For techies, the symptoms appear quite similar to serious fragmentation (or analogously for in-memory issues, garbage collection). I'm beginning to think that the core Flash filesystem code has a bug which starts to yield incorrect FS handling once many files are present. A key symptom is that attempts to restore from a backup will often report that the backup file is corrupted. My best guess is that the backup itself was probably performed properly, but the reported corruption actually may have been caused by the iPhone's filesystem itself becoming corrupted prior to the backup.
After having run into this issue often enough that I've needed to perform ~10 DFU restores on three iPhones (one original 8GB, and two 3G 16GB devices), this indeed appears to be a serious problem. Though my guess is that the iPhone's filesystem code is the root cause, I'm interested in hearing feedback from other folks who may have encountered this issue. Are the problems which you've seen consistent with this hypothesis?
Cheers!
Mark

Answer 1

Hello!
I'll add one more interesting data point. I've since found that I have had two different backup files that take well over an hour to restore onto a newly DFU-restored phone. On both of these files, the backup would proceed fairly quickly to a specific point (~50% on one file, and about 75% on the other file), and then would stop (the progress bar kept spinning, but with no forward progress) for about 1 hour, and then would continue and ultimately succeed. It's intriguing that repeating this process with each of these files yielded exactly the same "pause point".
While the thought of a timeout occurring is still quite appropriate, this further suggests that if the core filesystem code is at fault, the error might be induced by a NAND/iNAND error condition (NAND Flash always has errors, by design; Flash filesystems are supposed to handle those errors gracefully). This deterministic very-long-delay condition suggests that (normal) Flash errors just might be confusing the filesystem driver.
FYI!
Mark