Marc Roessler
04/17/2009 10:39 AM
post27353
|
Hi,
we are using ETFS on a 2K Nand flash in several of our products.
Quite some problems have shown up, and I'd be happy to get any feedback on what's happening here.
1. we seem to loose files / have corrupt spare areas...
We copied several files into the ETFS filesystem. After some reboots (without modifying the files in the mean time... we
usually shut down cleanly with "shutdown") ETFS reported corruption when starting/mounting it, and some of the files
vanished.
Starting ETFS driver for NAND flash...
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474176
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474177
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474178
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474179
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474180
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474181
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474182
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474183
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474184
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474185
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474186
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474187
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474188
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474189
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474190
fs-etfs-mpc8313erdb512-nand512: readtrans DATAERR on cluster 474191
fs-etfs-mpc8313erdb512-nand512: Truncating fid 0x18 from 16384 to 0 bytes
Starting ETFS success!
According to the source code, "readtrans DATAERR" means that the spare area is corrupted (damaged data, detected by
means of CRC errors).
2. I have tried to copy a file from ETFS to ETFS (i.e. create a duplicate under a different name). ETFS complained right
away that the file wouldn't fit into the partition (which is correct). After that, I got "cannot fork" when trying to
start additional processes via the shell. However, according to Momentics/qconn there was no unusual amount of processes
, so it can't be the process table being full...
This could only be fixed be rebooting.
Interestingly enough, after rebooting and trying the same command agin, ETFS did _NOT_ complain that the file wouldn't
fit into the partition and started copying happily.
3. I started copying the file as described above (copying to filename "x"), canceled the copy process (Ctrl-C) and
deleted the created file using "rm x". Right after rm exited, I powered down and rebootet. Upon booting/mounting, ETFS
complained about "readtrans DATAERR" on several clusters and reported a fid as truncated to 0. When looking into the /fs
/etfs dir, the "x" file was present again - with a file size of 0. How can that be? I thought file system actions were
handled as transactions? Either the file is deleted or it is not? Also I'm wondering why ETFS has a problem when
powering down (without shutdown) after "rm" has exited... as far as I understand from the ETFS descriptions, ETFS has no
independently running "background worker" thread but does everything "inline" with normal requests... so "rm" returning
should mean that the transaction has been finished and the file deleted correctly?
On a different note, I'm still a bit concerned about no ECC being used on the spare area. I had alread enquired about
this some time ago but got no real reply and forgot about it since. Now I've had my nose poked into this issue again due
to the above problems... Is this lack of ECC on the spare area a problem? Why/why not? Are there any plans on fixing it
in case it is a problem?
Greetings,
Marc
|
|
|