linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: David Jander <david.jander@protonic.nl>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: How reliable is jffs2 really (denx cvs devel kernel)?
Date: Wed, 20 Jul 2005 10:37:32 +0200	[thread overview]
Message-ID: <20050720083732.0BF7D352676@atlas.denx.de> (raw)
In-Reply-To: Your message of "Wed, 20 Jul 2005 08:30:26 +0200." <200507200830.27141.david.jander@protonic.nl>

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

      reply	other threads:[~2005-07-20  8:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-19  8:21 How reliable is jffs2 really (denx cvs devel kernel)? David Jander
2005-07-19 12:57 ` David Ho
2005-07-19 18:42   ` Wolfgang Denk
2005-07-19 19:03     ` David Ho
2005-07-19 18:37 ` Wolfgang Denk
2005-07-20  6:30   ` David Jander
2005-07-20  8:37     ` Wolfgang Denk [this message]

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=20050720083732.0BF7D352676@atlas.denx.de \
    --to=wd@denx.de \
    --cc=david.jander@protonic.nl \
    --cc=linuxppc-embedded@ozlabs.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 NNTP newsgroup(s).