[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

JFFS2 problems



David,
  I currently am using a 2.4.2 kernel (2.4.2-rmk1-np2-bse) on a Brightstar
Engineering NanoEngine with the MTD drivers for my flash (an auxiliary flash
that we have on the User bus) included in the kernel and the ext2
filesystem.
  We would like to use the JFFS2 (or the JFFS) filesystem on the flash.
Currently I have a fairly recent vintage from CVS and I am having problems
with file corruption and persistence.
  If I erase the flash, mount the filesystem, copy two small files to it and
make a directory, when I unmount it and mount it again, the directory is
gone.
  Do you have a recommendation on a recent version or snapshot that will
work with the 2.4.2 kernel?  Do you have any recommendations on how to debug
this problem?
  Thank you,
  Larry


-----Original Message-----
From: David Woodhouse [mailto:dwmw2@xxxxxxx.org]
Sent: Friday, October 05, 2001 8:53 AM
To: Ross, Lawrence
Cc: jffs-dev@xxxxxxx.com
Subject: Re: JFFS 

Lawrence.Ross@xxxxxxx.com said:
> In the function do_write_buffer() the calls to map->write8, map->
> write16, and  map->write32 pass the address of the buffer instead of
> the data to be written e.g. 
>     map->write16 (map, (((__u16*)buf)), adr+z);
> should be:
>     map->write16 (map, ((*(__u16*)buf)), adr+z); 

Yeah - there was some debate about that time as to whether we should be 
using get_unaligned() or not, and in the process of doing that and then 
reverting it we just stopped referencing the pointer altogether :) That 
was fixed some time ago.


>  I wasn't able to get the current CVS tree to work with my 2.4.2 ARM
> version of the kernel.  I will admit that I tried it, got some missing
> symbol problems that I didn't see an obvious fix for (something like
> put_user_bad), then went back and fixed the above problem. 

There was a patch for this on the mailing list a day or two ago. Basically 
ifdef out the case BLKGETSIZE64 from the ioctl routines.

	
>  I neither one worked for me out of the box.  The JFFS v1.0 has
> similar problems to the ones you describe, the file system is gone
> across a power cycle.  With JFFS v2.0 the filesystem is still there,
> but corrupted somehow. I am using the flash to store large (~1-2MB
> executables) and they are no longer executable.  I will try the latest
> JFFS filesystems from CVS to see if I can get them to work.

This is _after_ you fixed the above-mentioned problem? Then please give 
full reports of both, because they're not known problems.


>  David - a question for you with the MTD drivers.  How can I tell when
> the filesystem has been completely written to the flash?  It would be
> nice to know so I can be sure not to power down until it is done. 

All operations on the MTD devices except erase are synchronous. Erases of 
flash blocks have a callback. In fact, erases are synchronous too at the 
moment, but they won't always be that way - we'll check for completion from 
a timer. 

All operations on both JFFS and JFFS2 are synchronous too.

--
dwmw2


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com