The Journaling Flash File System for Linux

Creech, Matthew | 2 Feb 16:00

JFFS2 on dataflash problem

Hi,

Please forgive the cross-posting, but I'm not sure where exactly to go
with this problem.

I have an embedded device based on Atmel's AT91RM9200DK board, which is
using serial dataflash (AT45DB642).  I've allocated a JFFS2 partition to
store non-volatile data.  In testing I stumbled across a particular
problem that only occurs after heavy hammering on our device, but is
fairly consistent in how and when it occurs.  The pattern has been
narrowed down so that a script doing something like this:

while [ 1 ]; do
   cp /mnt/jffs2/$RANDOM_FILE /mnt/jffs2/$BLAH
   # File size has been tested between 8K and 64K
done

makes the problem occur within 24 to 36 hours.  So something about
copying one file over another one breaks things.  The "problem" here is
that every I/O operation having to do with the JFFS2 partition blocks
indefinitely.  For example, after running the test for 2 days, you can
log into the device and try to "ls" the contents of /mnt/jffs2, and your
shell will hang.  You can then login on another terminal, but you'll get
another hang if you try to have any interaction with the JFFS2
partition.  So everything else seems to function normally, but JFFS2
just dies.  Also note that rebooting the device sometimes fixes things
right up (JFFS2 mounts fine and works properly as if nothing happened at
all), but sometimes the filesystem image is corrupt and refuses to
mount.

(Continue reading)

Ulf Samuelsson | 2 Feb 22:32

Re: JFFS2 on dataflash problem

> I have an embedded device based on Atmel's AT91RM9200DK board, which is
> using serial dataflash (AT45DB642).  I've allocated a JFFS2 partition to
> store non-volatile data.  In testing I stumbled across a particular
> problem that only occurs after heavy hammering on our device, but is
> fairly consistent in how and when it occurs.  The pattern has been
> narrowed down so that a script doing something like this:

> while [ 1 ]; do
>   cp /mnt/jffs2/$RANDOM_FILE /mnt/jffs2/$BLAH
>   # File size has been tested between 8K and 64K
> done

If I wrote this script I would call it:

wear_out_dataflash_quickly.sh

There are some limitations to the number of erase cycles in the dataflash.
(IN any flash to be correct)
You can expect to reprogram it 50,000-100.000 times before the first errors
occur.
The second thing is that you need to do a block erase after the sum
of erases inside an 8 page block exceeds 10,000.

I am not at all sure that the MTD drivers/JFFS2 handle this (did not look at
the code).
I assume that JFFS may be able to detect a bad write and map
the block out from time to time, so this could explain why you can do the
recover.

If you really want to test the dataflash, write a CRC in the extra bytes

(Continue reading)

Adrian Bunk | 16 Feb 10:59

Picon

[2.6 patch] fs/jffs/: misc cleanups

This patch contains the following cleanups:
- make some needlessly global code static
- #if 0 the following unused functions:
  - intrep.c: jffs_print_file
  - jffs_fm.c: jffs_print_node_ref

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

This patch was already sent on:
- 8 Jan 2005
- 24 Jan 2005

 fs/jffs/inode-v23.c  |   10 +++----
 fs/jffs/intrep.c     |   60 ++++++++++++++++++++++++++++++-------------
 fs/jffs/intrep.h     |   32 +---------------------
 fs/jffs/jffs_fm.c    |   12 ++++++--
 fs/jffs/jffs_fm.h    |    6 +---
 include/linux/jffs.h |    1 
 6 files changed, 61 insertions(+), 60 deletions(-)

--- linux-2.6.10-mm2-full/fs/jffs/inode-v23.c.old	2005-01-08 04:00:49.000000000 +0100
+++ linux-2.6.10-mm2-full/fs/jffs/inode-v23.c	2005-01-08 04:01:36.000000000 +0100
@@ -334,7 +334,7 @@
 } /* jffs_notify_change()  */

 
-struct inode *
+static struct inode *

(Continue reading)

Adrian Bunk | 16 Feb 10:59

Picon

[2.6 patch] fs/jffs2/: misc cleanups

This patch contains the following cleanups:
- make some needlessly global functions static
- remove the following unused global functions:
  - compr.c: jffs2_set_compression_mode
  - compr.c: jffs2_get_compression_mode

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

This patch was already sent on:
- 8 Jan 2005
- 24 Jan 2005

 fs/jffs2/compr.c       |   10 ----------
 fs/jffs2/compr.h       |    3 ---
 fs/jffs2/compr_rtime.c |   12 ++++++++----
 fs/jffs2/erase.c       |    3 ++-
 fs/jffs2/file.c        |   15 +++++++++++----
 fs/jffs2/fs.c          |    3 ++-
 fs/jffs2/nodelist.h    |    1 -
 fs/jffs2/os-linux.h    |    5 -----
 fs/jffs2/wbuf.c        |    2 +-
 9 files changed, 24 insertions(+), 30 deletions(-)

--- linux-2.6.10-mm2-full/fs/jffs2/compr.h.old	2005-01-08 04:16:42.000000000 +0100
+++ linux-2.6.10-mm2-full/fs/jffs2/compr.h	2005-01-08 04:18:40.000000000 +0100
@@ -41,9 +41,6 @@
 #define JFFS2_COMPR_MODE_PRIORITY   1
 #define JFFS2_COMPR_MODE_SIZE       2

(Continue reading)

Muhammad Yahya | 24 Feb 00:13

Picon

Errors writing to flash

Hi,

I am running a PPC 875 board with Linux  2.4.25 and an 8MB flash.
When I try to write to the flash an image, as

>
> /tmp # wget -O - 
> http://129.148.183.102/~muhammad/flashupdate/spimage_nouboot |
> dd of=/dev/mtdblock0 bs=1k seek=256
> 7936+0 records in
> 7936+0 records out
>
> The write seems to go OK withiout any errors, but, on the console, we see
> the following messages which I an not sure if they are coming from 
> jffs or the mtd driver.
> Sometimes these messages are output right away after the write 
> completes and
> sometimes there is a delay before they are output:
>
>
> Node totlen on flash (0xffffffff) != totlen in node ref (0x000000c0)
> Node totlen on flash (0xffffffff) != totlen in node ref (0x00000064)
> Node totlen on flash (0xffffffff) != totlen in node ref (0x00000044)
>
> Any idea as to what this means and how to avoid this ? 

Thanks!
Muhammad

>

(Continue reading)

Andrew Lunn | 25 Feb 17:46

Picon

Possible bug in file truncation code

Hi Folks

Im tracking down a bug reported on the eCos mailing list. Please see
the thread:

http://ecos.sourceware.org/ml/ecos-discuss/2005-02/msg00319.html

In summary, the following causes the filesystem to be corrupted:

        fd = fopen("foobar", "w");
        fclose(fd);

ie openning a file so that it gets truncated and then closing
it. There ie an eCos test case in the thread.

I've looked at the code. The achive the truncation eCos does:

jffs2_truncate_fraglist(c, &f->fragtree, 0);

this in turn does

jffs2_obsolete_node_frag(c, frag);

for every fragment the node has. jffs2_obsolete_node_frag() has this
bit of code:

      if (!this->node->frags) {
		/* The node has no valid frags left. It's totally obsoleted */
		D2(printk(KERN_DEBUG "Marking old node @0x%08x (0x%04x-0x%04x) obsolete\n",
			  ref_offset(this->node->raw), this->node->ofs, this->node->ofs+this->node->size));

(Continue reading)

David Woodhouse | 25 Feb 18:21

Re: Possible bug in file truncation code

On Fri, 2005-02-25 at 17:46 +0100, Andrew Lunn wrote:
>ie if the node does not have any fragments left its marked as
>obsolete. These appears to remove the node, but still leaves it
>referenced in the directory. Hence the filesystem is corrupt.

Directories don't refer to data nodes. They refer to inodes. This inode
still exists and is zero-length because it has no valid data nodes. The
directory still refers to it -- that's fine. What's the actual problem?

--

-- 
dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com

Andrew Lunn | 25 Feb 18:43

Picon

Re: Possible bug in file truncation code

On Fri, Feb 25, 2005 at 05:21:41PM +0000, David Woodhouse wrote:
> On Fri, 2005-02-25 at 17:46 +0100, Andrew Lunn wrote:
> >ie if the node does not have any fragments left its marked as
> >obsolete. These appears to remove the node, but still leaves it
> >referenced in the directory. Hence the filesystem is corrupt.
> 
> Directories don't refer to data nodes. They refer to inodes. This inode
> still exists and is zero-length because it has no valid data nodes. The
> directory still refers to it -- that's fine. What's the actual problem?

The test case does the open, followed by a close then umount and then
mounts. The mount then reports:

<5>Eep. Child "TestFile.txt" (ino #10) of dir ino #1 doesn't exist!

I've attached the test case if you want to try it.

        Andrew

Attachment (jffs2_4.c): text/x-csrc, 1186 bytes

David Woodhouse | 25 Feb 18:59

Re: Possible bug in file truncation code

On Fri, 2005-02-25 at 18:43 +0100, Andrew Lunn wrote:
>
>The test case does the open, followed by a close then umount and then
>mounts. The mount then reports:
>
><5>Eep. Child "TestFile.txt" (ino #10) of dir ino #1 doesn't exist!

The inode #10 has no nodes at all, but it should have been left with one
-- a metadata node, which contains uid, gid, size, etc. information but
no data payload. This should have been written before calling
jffs2_truncate_fraglist(). 

Remember that the actual obsoletion of nodes on the medium is just an
optimisation, and it may not happen with NAND or other types of flash. 

Any truncation (to zero, or to any other length) should first write a
new node with the appropriate i_size, before calling
jffs2_truncate_fraglist().

If you support truncate-to-longer (Linux generally does but POSIX
doesn't require it) then your new metadata node should also have a data
payload make sure the space between the old EOF and the new EOF is
filled with zeroes and prevent old data from before a previous
truncation from 'showing through' where the file is now extended. Zeroes
compress quite easily with JFFS2_COMPR_ZERO -- there's no actual payload
on the medium at all.

See jffs2_do_setattr() in fs.c for the Linux version -- in Linux, that
function also handles changes to i_size.

(Continue reading)

Andrew Lunn | 25 Feb 21:28

Picon

Re: Possible bug in file truncation code

> Any truncation (to zero, or to any other length) should first write a
> new node with the appropriate i_size, before calling
> jffs2_truncate_fraglist().

Thanks David, that was what was wrong. The eCos code just set the
inode->isize to zero and did not create any new node.

I just committed the patch to eCos and mtd.

        Andrew

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com

Group

gmane.linux.file-systems.jffs.

Project Web Page

The Journaling Flash File System for Linux

Search Archive

Page

1 | 2

Articles in period: 10

February 2005

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

[AT91RM9200] further run-time problems (jffs2, Oops in __update_rq_clo (12 Nov 15:45)
jffs2_init_acl_post() can return uninitialized variable (27 Oct 16:18)
[2.6 patch] make jffs2_get_acl() static (24 Oct 18:27)
BUG at mm/filemap.c:1749 (2.6.24, jffs2, unionfs) (19 Oct 08:05)
jffs2 deadlock introduced in linux 2.6.22.5 (30 Aug 20:23)
[PATCH] Prefix each line of multiline printk(KERN_ "foo\nbar") (25 Aug 01:44)
[PATCH 2/4] Fix mainline filesystems to handle ATTR_KILL_ bits correct (20 Aug 22:53)
[PATCH 1/4] VFS: move ATTR_KILL handling from notify_change into helpe (20 Aug 22:53)
[PATCH 0/4] move handling of setuid/gid bits from VFS into individual (20 Aug 22:53)
[PATCH] [270/2many] MAINTAINERS - JOURNALLING FLASH FILE SYSTEM V2 (JF (13 Aug 08:30)
[PATCH 14/25] JFFS2: call attr_kill_to_mode from jffs2_do_setattr (6 Aug 15:54)
[PATCH 01/25] VFS: move attr_kill logic from notify_change into helper (6 Aug 15:54)
[PATCH 00/25] move handling of setuid/gid bits from VFS into individua (6 Aug 15:54)
[PATCH 14/25] JFFS2: call attr_kill_to_mode from jffs2_do_setattr (24 Jul 19:00)
[PATCH 01/25] VFS: move attr_kill logic from notify_change into helper (25 Jul 18:47)
[PATCH 00/25] move handling of setuid/gid bits from VFS into individua (25 Jul 18:47)
[2.6 patch] remove fs/jffs2/ioctl.c (29 Jul 17:02)
[RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible (29 Jul 17:02)
jffs2 statfs issue (19 Jul 12:01)
[1/3] 2.6.22-rc3: known regressions with patches v2 (1 Jun 21:41)
[1/3] 2.6.22-rc3: known regressions with patches v2 (1 Jun 14:21)

Archives

2	November 2007
11	October 2007
7	September 2007
38	August 2007
9	July 2007
2	June 2007
4	May 2007
1	April 2007
2	March 2007
2	February 2007
6	January 2007
19	December 2006
2	November 2006
3	October 2006
4	September 2006
2	August 2006
9	July 2006
6	June 2006
8	May 2006
2	January 2006
6	December 2005
8	November 2005
2	October 2005
9	September 2005
8	August 2005
4	July 2005
10	May 2005
9	April 2005
9	March 2005
10	February 2005
6	January 2005
22	December 2004
12	November 2004
39	October 2004
24	September 2004
6	August 2004
17	July 2004
5	June 2004
28	May 2004
14	April 2004
11	March 2004
12	February 2004
8	December 2003
6	November 2003
22	October 2003
22	September 2003
22	August 2003
9	July 2003
9	June 2003
5	April 2003
13	March 2003
1	January 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template