Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Flash File System?

Flash File System?

2005-09-19 by Chris

What alternatives are there for a flash file system for the LPCxxxx?

- Chris Graham

Re: [lpc2000] Flash File System?

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.

RE: [lpc2000] Flash File System?

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

Re: [lpc2000] Flash File System?

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

Re: [lpc2000] Flash File System?

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.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.