NAND flash question

NAND flash question

[Charles Tilbury]

I have a bug fix and a question.  

First the bug fix:

There are some NAND flash parts that have an undocumented busy time after an 
address is passed to it.  I am working with the 16M byte x 8 bit Toshiba part 
that has this.  I am using the default "command" function.  In order to get 
it to work, I added a check to see if the part is busy _before_ I try to 
submit a command to the part.  If the part is not busy, then the test just 
falls through.

Now the question:

I am using an ST Micro 64M byte x 8 bit flash part and JFFS2.  It mostly works 
except that when the board reboots, JFFS2 reports CRC error messages when the 
partition mounts again.  The strange part is that there does not seem to be 
any data corruption or lost data.  Also, I do not see any error messages 
while reading and writing.  However, the CRC errors seem to accumulate over 
time.  Is there some way to prevent this from happening?  Repair it?  Should 
I just ignore it?

Thanks in advanse,
Charles Tilbury
Seattle, WA
USA

Re: NAND flash question

[Sergei Sharonov]

Charles,
> I am using an ST Micro 64M byte x 8 bit flash part and JFFS2.  It mostly works 
> except that when the board reboots, JFFS2 reports CRC error messages when the 
> partition mounts again.  The strange part is that there does not seem to be 
> any data corruption or lost data.  Also, I do not see any error messages 
> while reading and writing.  However, the CRC errors seem to accumulate over 
> time.  Is there some way to prevent this from happening?  Repair it?  Should 
> I just ignore it?


In my experience these "errors" occur if you switch of the power without
proper shutdown. They are not errors really, just notes from JFFS2 that
some write was interrupted by power cycle or reset and the node written is
invalid. It is annoying but harmless. I believe they eventually go away
after the block is reclaimed by GC.

Sergei

Re: NAND flash question

[Artem B. Bityuckiy]

On Mon, 2005-06-27 at 14:09 -0700, Charles Tilbury wrote:
> I am using an ST Micro 64M byte x 8 bit flash part and JFFS2.  It mostly works 
> except that when the board reboots, JFFS2 reports CRC error messages when the 
> partition mounts again.  The strange part is that there does not seem to be 
> any data corruption or lost data.  Also, I do not see any error messages 
> while reading and writing.  However, the CRC errors seem to accumulate over 
> time.  Is there some way to prevent this from happening?  Repair it?  Should 
> I just ignore it?
As Sergey said, these errors appear because of unclean reboots you do.
Normally they are harmless. Yes, ignore them.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: NAND flash question

[Charles Tilbury]

Yes. Thanks.  Now, I am looking for a way to get the file systems unmounted 
upon loss of power.

Thanks Guys,
-=Charles Tilbury=-

On Tuesday 28 June 2005 12:23 am, Artem B. Bityuckiy wrote:
> On Mon, 2005-06-27 at 14:09 -0700, Charles Tilbury wrote:
> > I am using an ST Micro 64M byte x 8 bit flash part and JFFS2.  It mostly
> > works except that when the board reboots, JFFS2 reports CRC error
> > messages when the partition mounts again.  The strange part is that there
> > does not seem to be any data corruption or lost data.  Also, I do not see
> > any error messages while reading and writing.  However, the CRC errors
> > seem to accumulate over time.  Is there some way to prevent this from
> > happening?  Repair it?  Should I just ignore it?
>
> As Sergey said, these errors appear because of unclean reboots you do.
> Normally they are harmless. Yes, ignore them.

Re: NAND flash question

[Artem B. Bityuckiy]

Charles Tilbury wrote:
> Yes. Thanks.  Now, I am looking for a way to get the file systems unmounted 
> upon loss of power.

I assume you don't look for this in order to get rid of these messages ?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: NAND flash question

[Charles Tilbury]

On Tuesday 28 June 2005 9:06 am, Artem B. Bityuckiy wrote:
> Charles Tilbury wrote:
> > Yes. Thanks.  Now, I am looking for a way to get the file systems
> > unmounted upon loss of power.
>
> I assume you don't look for this in order to get rid of these messages ?

(sorry about the prev. top-post)

In part, I want to get rid of the messages.  They make the marketing guys 
nervous.  <<grin>>  I may just supress them using comments.  What I really 
need is to make sure that the user land data gets flushed to NAND before 
power loss.   That seems like a JFFS2 issue, do you agree?

-=CharlesT=-

Re: NAND flash question

[David Woodhouse]

On Tue, 2005-06-28 at 09:41 -0700, Charles Tilbury wrote:
> In part, I want to get rid of the messages.  They make the marketing
> guys nervous.  <<grin>>  I may just supress them using comments.  What
> I really need is to make sure that the user land data gets flushed to
> NAND before power loss.   That seems like a JFFS2 issue, do you agree?

Not really. Userland data are flushed to the medium on fsync() or sync()
just as with other file systems. If a write() call has _just finished
when the power is lost, there's no guarantee that _any_ file system will
have committed that write to the medium already. (Unless you were using
O_SYNC, which we don't support for JFFS2).

-- 
dwmw2

Re: NAND flash question

[Charles Tilbury]

On Tuesday 28 June 2005 11:30 am, David Woodhouse wrote:
> On Tue, 2005-06-28 at 09:41 -0700, Charles Tilbury wrote:
> > In part, I want to get rid of the messages.  They make the marketing
> > guys nervous.  <<grin>>  I may just supress them using comments.  What
> > I really need is to make sure that the user land data gets flushed to
> > NAND before power loss.   That seems like a JFFS2 issue, do you agree?
>
> Not really. Userland data are flushed to the medium on fsync() or sync()
> just as with other file systems. If a write() call has _just finished
> when the power is lost, there's no guarantee that _any_ file system will
> have committed that write to the medium already. (Unless you were using
> O_SYNC, which we don't support for JFFS2).

How could one change the flush interval to around 100mS?  Or does that sound 
like a stupid idea?

Re: NAND flash question

[Sergei Sharonov]

Charles,
> How could one change the flush interval to around 100mS?  Or does that sound 
> like a stupid idea?

Just call sync/fsync as needed. Your application should know when to do it.
Secondly, I believe JFFS2 will flush write buffer no latter then 5 s after 
write (?). Can anybody comment on that?

Sergei

Re: NAND flash question

[Artem B. Bityuckiy]

On Tue, 2005-06-28 at 19:20 +0000, Sergei Sharonov wrote:
> Charles,
> > How could one change the flush interval to around 100mS?  Or does that sound 
> > like a stupid idea?
> 
> Just call sync/fsync as needed. Your application should know when to do it.
> Secondly, I believe JFFS2 will flush write buffer no latter then 5 s after 
> write (?). Can anybody comment on that?
> 
The write buffer flushing mechanism works as follows.

Every time something is written to the WB, the in-RAM superblock
structure object is marked as dirty (sb->s_dirt = 1). pdflush daemon is
the standard daemon which periodically wakes up and flushes dirty pages
and superblocks. So, the jffs2_write_super() will be called by pdflush
when the dirty interval is expired, and the WB will be flushed (and of
course, the s_dirty flag is cleaned). This flushing delay take a chance
that the next writes will be merged with the previous writes before the
WB is flushed.

The dirty expire interval is adjusted by means
of /proc/sys/vm/dirty_expire_centisecs
(seeDocumentation/filesystems/proc.txt) for details.

HTH.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: NAND flash question

[Artem B. Bityuckiy]

On Tue, 2005-06-28 at 19:30 +0100, David Woodhouse wrote:
> On Tue, 2005-06-28 at 09:41 -0700, Charles Tilbury wrote:
> > In part, I want to get rid of the messages.  They make the marketing
> > guys nervous.  <<grin>>  I may just supress them using comments.  What
> > I really need is to make sure that the user land data gets flushed to
> > NAND before power loss.   That seems like a JFFS2 issue, do you agree?
> 
> Not really. Userland data are flushed to the medium on fsync() or sync()
> just as with other file systems. If a write() call has _just finished
> when the power is lost, there's no guarantee that _any_ file system will
> have committed that write to the medium already. (Unless you were using
> O_SYNC, which we don't support for JFFS2).
> 
This all is correct. But IMO the question implied that the messages like
this are too scary:

jffs2_get_inode_nodes(): CRC failed on node at 0x%08x: Read 0x%08x,
calculated 0x%08x.

And I tend to agree with this. Unclean reboots are normal in embedded
devices and it would be nice not to frighten people by such messages,
especially because in 99% cases this is harmless - just the last written
data is lost. And this is not the first time people are confused with
that. But unfortunately, it is difficult to distinguish between CRC
errors caused by unclean reboots and by real media corruptions, so I
prefer to print this rather then to be silent.

If someone has come up with a patch which smartly distinguishes the CRC
errors reason I'd be very glad.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.