Flash File System?
2005-09-19 by Chris
Yahoo Groups archive
Index last updated: 2026-04-28 23:31 UTC
Thread
2005-09-19 by Chris
What alternatives are there for a flash file system for the LPCxxxx? - Chris Graham
2005-09-20 by Charles Manning
On Tuesday 20 September 2005 03:39, Chris wrote: > What alternatives are there for a flash file system for the LPCxxxx? It depends on what you want to do..... If you only need to store small amounts of data (or even large amounts with a simple append or save-over policy) then a full-blown file system is overkill. If you need to share the media (eg. CF or SD) with a PC, then you'll probably want FAT. FAT is, however, rather unreliable. Log structured file systems designed for flash (eg. JFFS2 or YAFFS) are far more reliable. #disclaimer. I wrote YAFFS and have been kicked in the ***** by FAT too many times.
2005-09-20 by Lasse Madsen
Hi Charles, >If you only need to store small amounts of data (or even large amounts with >a simple append or save-over policy) then a full-blown file system is >overkill. I agree >If you need to share the media (eg. CF or SD) with a PC, then you'll >probably want FAT. There is no other alternative...AFAIK >FAT is, however, rather unreliable. Log structured file systems designed >for flash (eg. JFFS2 or YAFFS) are far more reliable. I disagree strongly... I have written my own FAT16 driver which I used prior to using the PRLLC source code solution and I've never toasted the files so badly that scandisk couldn't save them, and thinking about the many megabytes I have written to both secure digital and compact flash cards I think it's a nice statistic. >#disclaimer. I wrote YAFFS and have been kicked in the ***** by FAT too >many times. What where your problems? Regards Lasse Madsen Yahoo! Groups Links
2005-09-20 by 42Bastian Schick
Lasse Madsen <Lasse.Madsen@...> schrieb am Tue, 20 Sep 2005 09:48:29 +0200: >> If you need to share the media (eg. CF or SD) with a PC, then you'll >> probably want FAT. > > There is no other alternative...AFAIK Sure. MINIX-FS, ext2 etc. ( ok, most think of a Wintel PC when saying PC). But even on Windows, it is a driver-issue, isn't it ? -- 42Bastian Schick
2005-09-20 by Charles Manning
On Tuesday 20 September 2005 19:48, Lasse Madsen wrote: > Hi Charles, > > >If you only need to store small amounts of data (or even large amounts > > with a simple append or save-over policy) then a full-blown file system > > is overkill. > > I agree > > >If you need to share the media (eg. CF or SD) with a PC, then you'll > >probably want FAT. > > There is no other alternative...AFAIK Given the original poster's desires to not use any special drivers/fs I think this is the case. You could, in theory at least, install other drivers/fs for any file system you choose. There is however USB PTP which does provide a file oriented interface. Perhaps this could be useful. I have not read enough to determine if it is limited to pictures or could be used for other data too. > > >FAT is, however, rather unreliable. Log structured file systems designed > >for flash (eg. JFFS2 or YAFFS) are far more reliable. > > I disagree strongly... I have written my own FAT16 driver which I used > prior to using the PRLLC source code solution and I've never toasted the > files so badly that scandisk couldn't save them, and thinking about the > many megabytes I have written to both secure digital and compact flash > cards I think it's a nice statistic. It so much depends on being able to get clean dismounts etc and the way it is used. Mileage will vary. Pull a FAT volume out of a laptop before you dismount it cleanly and see what happens. Adding scandisk and other repairs to an embedded device is not a real scenario. I have never seen a camera or such provide any such tools. Asking consumers to run scandisk is way more than "plug-and-play Joe" can handle. Even Microsoft are now telling people to switch to using TFAT (their transaction safe version of FAT) because FAT is too unreliable for smart phones etc. TFAT is still relatively unproven and is slower than FAT. I have dealt with quite a few projects where FAT has not been able to do the job properly and data has been lost. Worst still, a FAT failure can kill files other than the ones you have open. A few weeks ago, my laptop hard disk started behaving badly so I decided to back up the disk onto a USB hard drive. Unfortunately the laptop disk died completely before the operation was complete. This caused Windows to crash. Unfortunately therefore the USB drive was not left in a consistent state and the data was toast (even data that was already happily on the disk). Last week the USB plug fell out of my MP3 player (mounted as a USB mass storage) as I was loading new songs. I had to reformat the MP3 player. Datalight, as part of their sales pitch for their Reliance file system, make the case that FAT failures account for a high % of system failures in embedded systems. From what I have seen, I have to agree. I don't however agree with a lot of what they write regarding comparisons to log structured fs. Datalight Reliance is a transactional file system, AFAIK. It is supposed to be faster than TFAT. > > >#disclaimer. I wrote YAFFS and have been kicked in the ***** by FAT too > >many times. YAFFS and JFFS2 are both log structured. Log structured file systems have no FAT-like tables that can get scrambled. I have not done any JFFS2 testing personally, but YAFFS is faster (write speed) than FAT too - mainly because there is no need to update tables on the media.