public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Gunnar Ruthenberg" <Krill.Plush@gmx.net>
To: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] JFFS2 bug with overwriting files bigger than 50% of the file system?
Date: Tue, 09 Aug 2011 14:52:00 -0000	[thread overview]
Message-ID: <20110809145222.265360@gmx.net> (raw)
In-Reply-To: <4E379C57.2020503@televic.com>


Hi,

> >
> > Hi,
> >
> > I stumbled upon a problem with JFFS2.
> >
> > When overwriting a relatively large file (580 kB in a 896 kB flash 
> > region),
> > the file system breaks.
> >
> What is your block size, or more precisely, the size of the erase blocks?
> Often it is 128kB.
> JFFS2 needs some spare blocks for garbage collection. I don't remember 
> if the default is 3 or 5.
> 3 means 384kB, so only 512kB is available. And if you still force to use 
> it, it _will_ give problems.
> >

The block size is 64 kB, and there are 14 blocks in total.

The file takes up 6 blocks (with compression), so 8 blocks are free.

These are the settings for the amount of reserved blocks:

resv_blocks_write = 3,
resv_blocks_deletion = 2,
resv_blocks_gctrigger = 4,
resv_blocks_gcbad = 0,
resv_blocks_gcmerge = 3.

If I understood you correctly, deleting and saving the file again should work
fine by these numbers.

I tried increasing the FS size by 8 blocks, but the problem still persists.

After that I tried to run the GC from application code between deleting and
re-writing the file, but saw that this isn't possible without some ugly hacks,
so I decided to reply to this ML first before getting down to that (depending
on the answer).

Anyhow, the GC should be run before re-writing the file anyways, if I under-
stood things right, so triggering it manually would probably not help either.

> >
> > Plenty of errors like these ensue when trying to read the new, 
> > overwritten file
> > after a reboot:
> >
> > BUG() at ~/ecos-2.0.40/packages/fs/jffs2/v2_0_40/src/readinode.c 381
> > <5>JFFS2 notice:  read_unknown: node header CRC failed at %#08x. But 
> > it must hav
> > e been OK earlier.
> > <4>Node totlen on flash (0xffffffff) != totlen from node ref
> (0x00000044)
> > <4>JFFS2 warning:  jffs2_do_read_inode_internal: no data nodes found 
> > for ino #3
> > <5>JFFS2 notice:  jffs2_do_read_inode_internal: but it has children so 
> > we fake s
> > ome modes for it
> > <4>JFFS2 warning:  jffs2_do_read_inode_internal: no data nodes found 
> > for ino #3
> > <5>JFFS2 notice:  jffs2_do_read_inode_internal: but it has children so 
> > we fake s
> > ome modes for it
> >
> > It does not matter if the new file is identical with the old file.
> > Unlinking and then writing the file again causes the same result.
> >
> FYI: JFFS2 is a log based file system, better read about it if you don't 
> know that (I can give some pointers). It means that you cannot overwrite 
> a file: instead, the file is marked (in the file system meta data or 
> table of contents) for removal, and the new version of the file is 
> appended in the file system. If the file system is full, garbage 
> collection (GC) starts to recover blocks, using those spare blocks.
> And GC can take some time (and then all file system accesses are frozen, 
> e.g. the TFTP server), resulting e.g. in a TFTP timeout in the client. 
> And if GC can free a block, and then the client resends a TFTP packet, 
> the same data portion can be present in double... I have seen several 
> file system problems when stress testing it..
> Also mark that on a flash you cannot delete bytes, only per erase block.


Thanks, I had a vague concept of journalling or log-based filesystems in
mind, but never looked at the details.


> > If this is more or less a known problem, how likely is it that small 
> > files (say,
> > being smaller than 50% of the file system's storage space) cause this 
> > behaviour
> > as well?
> >
> > I noticed that the current version in the eCos source tree lags a bit 
> > behind the
> > code in the Linux kernel. Maybe this issue has been fixed there 
> > already and only
> > requires a port of the current code to eCos.
> >
> indeed, already for a long time a volunteer is needed to update the ecos 
> jffs2 code.
> 
> Regards,
> Jürgen
> >
> >
> > I'd be grateful for any ideas about this problem, even if it is just 
> > pointing me
> > to the linux-mtd mailing list.
> >
> > Thanks,
> >
> > Gunnar Ruthenberg.
> >
> 

Any more suggestions?

Thanks,

Gunnar Ruthenberg.

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2011-08-09 14:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-28 13:15 Gunnar Ruthenberg
2011-07-28 13:36 ` Gunnar Ruthenberg
2011-08-02  6:42 ` Lambrecht Jürgen
2011-08-09 14:52   ` Gunnar Ruthenberg [this message]
2011-08-11  6:51     ` Lambrecht Jürgen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110809145222.265360@gmx.net \
    --to=krill.plush@gmx.net \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).