The only way to be sure about what happened with these phones is to
bring one in and have someone who understands filesystems check them
out and see what's wrong with them. It could be a software error, or
it could be a hardware error. Jumping to conclusions without testing
those same conclusions could result in you chasing ghosts.
There have been some stories about flash drives failing because of too
many rewrites in one location (caused by things like access time
updates and journaling). That's probably something worth excluding
before you presume that the cause is untimely power cycling.
There are, apparently some filesystems that are purposely designed to
be used on flash drives, and the like. These are probably going to be
far more useful to you than an ext3 filesystem.
(among other things, the ext3 filesystem is designed to implicitly
minimize fragmentation, which increases access times. This isn't as
much an issue with solid state devices, and there may be other
things to worry about, like rewrite fatigue.
On 7/27/07, Alvin Cao <alvin.cao at gmail.com>
wrote:> Dear All,
>
> Our mobile device, which runs linux 2.4, uses ext3 as its filesystem.
> To make ext3 work, we have Samsung's xrs module, a middle layer which
> resembles MTD, to simulate disk devices over Samsung's onenand flash.
> Recently some of our phones are suffering a filesystem crash with only
> 30% space used on that partition. So I began to doubt whether it is
> right to employ an disk filesystem on an embedded system. It seems the
> kjournald kernel thread sends out an oops. Just assuming the xrs layer
> simulates perfectly a real disk device, I want to discuss what the
> disadvantages or advantages, if there is any, are in such a design.
>
> I think the point is that to keep ext3 safe, we must umount these
> devices cleanly before rebooting to let the kernel flush useful
> information to the disks. On a PC we don't do many reboots. Even dirty
> reboots without umount happen, data are very likely to be recovered.
> And yet we have experienced administrators and uitilities like e2fsck
> to resort to. But even then there are still chances that disks could
> fail.
>
> Embedded systems are quite different. Developers and customers could
> pull out the battery at all times. It's unpredictable. Consequently
> there should be much more chances than on a PC that a disk failure
> happen. And we can't bet on the customers. Once the products are
> delivered to our customers, any disk failure, either recoverable(I
> think it's the most cases) or unrecoverable, is unacceptable. We
can't
> expect the customers do what we are supposed to do.
>
> Guys, I really want polish the products as much as I can. Please give
> your comments on what kind of risks we may take by using ext3 in such
> a design. And if you have rich experience of using ext3 in an embedded
> system, great, please feel free to share it. Any helps are
> appreciated.
--
Stephen Samuel http://www.bcgreen.com
778-861-7641