How reliable is jffs2 really (denx cvs devel kernel)?

How reliable is jffs2 really (denx cvs devel kernel)?

[David Jander]

Hi,

I have seen some strange problems with jffs2. I have been victim of the BUG() 
in fs/jffs2/gc.c, line 139. I have been battling with kgdb to see what 
happens there. Here are my findings until now (I am still working on this):

c->checked_ino starts counting from 0
c->highest_ino is 92 (????)

Isn't this a little low?

Flash partition size is 15Mbyte, it probably has been mistreated by writing 
large files (logfiles) line by line, wasting a lot of space until it gets 
almost full.
When debugging the for(;;) loop, used size starts from a few kb counting up, 
dirty size is around 5 Mb and unchecked size is about 9.9Mb, so when it gets 
past inode 92 it most probably has still a lot of unchecked space.===> BUG().

Googleing for this bug, I have found discouraging e-mails (luckily most of 
them from 2003 or older) saying that this is common and nobody (back then) 
seemed to know where it came from. Bugs in fjjs2 code, etc....

This is scaring me.

Anybody knows more about this problem, why it is caused, and hopefully how to 
prevent this?

Thanks,

-- 
David Jander

Re: How reliable is jffs2 really (denx cvs devel kernel)?

[David Ho]

I ran into similar problems, I had talked to David Woodhouse about a
number of issues with JFFS2.  But he has no plans to support 2.4
kernels.

There are a bunch of people that back ports the latest JFFS2 code from
2.6 and snapshots are found here
ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/.

I updated the JFFS2 portion of the Denx devel kernel with the latest
from CVS and it solved the initial mount time problem.  But it was a
while a ago when I did this.  Both the devel kernel and the CVS head
has changed quite a bit since then.

But some people on the mailing list seem to indicate timing resolution
in the 2.4 leading to race condition, or some other deficiency from
what I recall.

The people in the mailing list were not interested in fixing these so
called kernel bugs.  And since JFFS2 code is too complex for my spare
time and it does not cause the kernel to hang, I have yet to figure
out a fix for it.

I like to know other's experience with JFFS2 on 2.4 as well.

David


On 7/19/05, David Jander <david.jander@protonic.nl> wrote:
>=20
> Hi,
>=20
> I have seen some strange problems with jffs2. I have been victim of the B=
UG()
> in fs/jffs2/gc.c, line 139. I have been battling with kgdb to see what
> happens there. Here are my findings until now (I am still working on this=
):
>=20
> c->checked_ino starts counting from 0
> c->highest_ino is 92 (????)
>=20
> Isn't this a little low?
>=20
> Flash partition size is 15Mbyte, it probably has been mistreated by writi=
ng
> large files (logfiles) line by line, wasting a lot of space until it gets
> almost full.
> When debugging the for(;;) loop, used size starts from a few kb counting =
up,
> dirty size is around 5 Mb and unchecked size is about 9.9Mb, so when it g=
ets
> past inode 92 it most probably has still a lot of unchecked space.=3D=3D=
=3D> BUG().
>=20
> Googleing for this bug, I have found discouraging e-mails (luckily most o=
f
> them from 2003 or older) saying that this is common and nobody (back then=
)
> seemed to know where it came from. Bugs in fjjs2 code, etc....
>=20
> This is scaring me.
>=20
> Anybody knows more about this problem, why it is caused, and hopefully ho=
w to
> prevent this?
>=20
> Thanks,
>=20
> --
> David Jander
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: How reliable is jffs2 really (denx cvs devel kernel)?

[Wolfgang Denk]

In message <200507191021.52063.david.jander@protonic.nl> you wrote:
> 
> I have seen some strange problems with jffs2. I have been victim of the BUG() 
> in fs/jffs2/gc.c, line 139. I have been battling with kgdb to see what 
> happens there. Here are my findings until now (I am still working on this):

You probably want to ask this on the MTD mailing list;  don't  forget
to  mention  the  exact  version of the MTD / JFFS2 code you're using
(see CVS history).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Success in marriage is not so much finding the right person as it  is
being the right person.

Re: How reliable is jffs2 really (denx cvs devel kernel)?

[Wolfgang Denk]

In message <4dd15d1805071905573ebcba61@mail.gmail.com> you wrote:
>
> I updated the JFFS2 portion of the Denx devel kernel with the latest
> from CVS and it solved the initial mount time problem.  But it was a
> while a ago when I did this.  Both the devel kernel and the CVS head
> has changed quite a bit since then.

I would rally appreciate if you mentioned which exact version of  the
kernel you are talking about. "The Denx devel kernel" can be anything
- either yesterday or 3 years old.

At the moment our CVS tree contains a snapshot from MTD CVS of  March
13, 2005; yes, we did the necessary backport to the 2.4 kernel.

Do you want to say that this version still  has  mount  time  issues?
Please provide details!


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to  the
purpose of sitting around all day and eating big heavy meals.
                                 - Terry Pratchett, _Moving Pictures_

Re: How reliable is jffs2 really (denx cvs devel kernel)?

[David Ho]

Wolfgang,

It must have be more than a year ago that I did this.   And I have not
done any testing with the latest devel kernel from your CVS so I am
not making any conclusion about the latest kernel.

Just trying to be helpful. =20

The mount time issue is fixed a long time ago, so your back port most
probably has this fix.

David

On 7/19/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <4dd15d1805071905573ebcba61@mail.gmail.com> you wrote:
> >
> > I updated the JFFS2 portion of the Denx devel kernel with the latest
> > from CVS and it solved the initial mount time problem.  But it was a
> > while a ago when I did this.  Both the devel kernel and the CVS head
> > has changed quite a bit since then.
>=20
> I would rally appreciate if you mentioned which exact version of  the
> kernel you are talking about. "The Denx devel kernel" can be anything
> - either yesterday or 3 years old.
>=20
> At the moment our CVS tree contains a snapshot from MTD CVS of  March
> 13, 2005; yes, we did the necessary backport to the 2.4 kernel.
>=20
> Do you want to say that this version still  has  mount  time  issues?
> Please provide details!
>=20
>=20
> Best regards,
>=20
> Wolfgang Denk
>=20
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> The word "fit", as I understand it, means "appropriate to a purpose",
> and I would say the body of the Dean is supremely appropriate to  the
> purpose of sitting around all day and eating big heavy meals.
>                                  - Terry Pratchett, _Moving Pictures_
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: How reliable is jffs2 really (denx cvs devel kernel)?

[David Jander]

On Tuesday 19 July 2005 20:37, you wrote:
>[...]
> You probably want to ask this on the MTD mailing list;  don't  forget
> to  mention  the  exact  version of the MTD / JFFS2 code you're using
> (see CVS history).

I already thought it might be a good idea to subscribe to that list.
Any hint about how I can figure out exactly which version of MTD code I have?
The version of linuxppc_2_4_devel I have is about 2 months old, do I have to 
expect important changes concerning MTD since then?

While we are there, what other solution would you suggest for this problem: We 
need to log data into flash. Right now I use an oversized jffs2 partition, 
log via syslogd and logrotate on size. I am getting the impression that this 
is not workable for mission critical things. At least not with the kernel and 
MTD code I have. Others must have the same problem, so here's my question: 
Which way to do such a thing? Write my own filesystem?

Greetings,

-- 
David Jander

Re: How reliable is jffs2 really (denx cvs devel kernel)?

[Wolfgang Denk]

In message <200507200830.27141.david.jander@protonic.nl> you wrote:
> 
> I already thought it might be a good idea to subscribe to that list.
> Any hint about how I can figure out exactly which version of MTD code I have?

I already answered this in my previous message: it's a snapshot  from
MTD CVS of March 13, 2005, backported to the 2.4 kernel.

In general, you can find this type of information when  checking  the
CVS  history.  That's  why  we  run a CVS server and not only provide
tarballs.

> The version of linuxppc_2_4_devel I have is about 2 months old, do I have to 
> expect important changes concerning MTD since then?

More changes have been made since, of course, but I'm  not  aware  of
anything that might be relevant to your problem.

> need to log data into flash. Right now I use an oversized jffs2 partition, 
> log via syslogd and logrotate on size. I am getting the impression that this 

This is about the worst case use for JFFS2 - always  appending  small
chunks (sinlge lines of text) to an ever growing file is exactly what
the filesystem was NOT designed for.

> is not workable for mission critical things. At least not with the kernel and 
> MTD code I have. Others must have the same problem, so here's my question: 
> Which way to do such a thing? Write my own filesystem?

No. Don't reinvent the wheel. Use a buffer are with  unlimited  write
cycles  (like  SRAM  or FRAM), or even a reserved area of your system
RAM, and use pramfs on it. If  you're  using  U-Boot,  you  can  even
arrange that such a file system survives warm boots. Then establish a
policy  for writing the data from this buffer area to flash (probably
still using JFFS2) at a much lower rate. Avoid append  mode.  Try  to
write files in a single operation. etc.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Summit meetings tend to be like panda matings. The expectations  are
always high, and the results usually disappointing."   - Robert Orben