>On the other hand, if you're building an embedded system for a lunar >lander for Apollo 13, or a real time control system, then I would argue >that you should squeeze in as many engineering cycles as you can, >because a dependable system is only as robust as its weakest link. I disagree. What you are building does not change the truism. All that happens is that 'good enough' has a more stringent definition - that's the whole point. >Having said that, I don't think James initially knew that a CF does >wear-levelling - so perhaps he doesn't have that much direct experience >with these devices. I thought I made the point that I believe many do. But once again the issue here is not whether the do or not, its whether wear-levelling is a requirement. A modern flash device will handle many updates per sector, and a device that runs from flash is presumably intended not to be update-heavy. So long as you don't perform unnecessary housekeeping IO's such as flushing access times frequently, then you'll generally be fine. Do the maths. Systems tend to update /tmp and /var quite a lot, even then if you can avoid flushing the sectors with directories and delaying them, then you can get to a the point where the design life is not limited by the flash device. >Putting on my selfish hat I'd love to have a filesystem that could run >directly on raw flash. Why? Lets remember we're talking about an embedded system that can be sensibly implemented with a general purpose OS. I'd put it to you that normally where this is very desirable, its because the run rate is quite low so the project overall is very sensitive to ease and cost of development. But if the run rate is low, then you also need to consider what hardware will be available in volume at go-live, and CF-to-IDE is very cheap now in conjunction with system-on-a-chip designs for set top boxes. For big bulk, we have PIC, Atmel, Rabbit, and assorted 80186 designs (including one very cute thing I saw built into an ethernet PHY) If you really must wear level, then why not access through a layer that divides the whole CF into 'n' partitions, uses 'n-1' of them, re- presents the 'n-1' through a RAID0-like mapping, and allows the logical sector 0 in each partition to be changed (with wrap-around). Then you can use a real filesystem on top of the block-mapping layer, and the mapper can move the hotspot around the disk much as a RAID array can rebuild under a real system.Received on Sat May 27 2006 - 12:09:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:56 UTC