From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1605 invoked by alias); 16 Oct 2003 07:23:36 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 1568 invoked from network); 16 Oct 2003 07:23:34 -0000 Received: from unknown (HELO mail.broadpark.no) (217.13.4.2) by sources.redhat.com with SMTP; 16 Oct 2003 07:23:34 -0000 Received: from famine (217-13-20-38.dd.nextgentel.com [217.13.20.38]) by mail.broadpark.no (Postfix) with ESMTP id E083179A94 for ; Thu, 16 Oct 2003 09:23:33 +0200 (MEST) From: =?ISO-8859-1?Q?=D8yvind?= Harboe To: ecos-discuss@sources.redhat.com Content-Type: text/plain; charset=UTF-8 Organization: Zylin AS Message-Id: <1066289013.5833.24.camel@famine> Mime-Version: 1.0 Date: Thu, 16 Oct 2003 07:23:00 -0000 Content-Transfer-Encoding: 8bit Subject: Re: [ECOS] Stress testing JFFS2 X-SW-Source: 2003-10/txt/msg00282.txt.bz2 W.r.t. actual usage of JFFS2, here are the "parameters" for our usage: - We need a capability to persit options(i.e. various named parameters that are anything from a couple of bytes to a couple of k in size). These parameters are updated frequently during configuration phases and only read during normal operation. The total number of files is ~10-30. This configuration JFFS2 image is 6x64k. Possible alternative: Redboot parameters? - The configuration parameters are only read during startup. Afterwards, it would be advantagous to flush all ram that JFFS2 is using. JFFS2 can evidently rebuild the ram nodes more than quickly enough. - During production we have a phase where the a second JFFS2 image is modifyable(where we store, e.g. serial number). This JFFS2 image is afterwards write protected in hardware. This JFFS2 image is 1x64k, hence my previous posts about tricks to get JFFS2 to deal with this. Romdisks could have been an alternative here, but the tools are designed to run on the developer machine. The needs above could be covered by other solutions. However, I like JFFS2, because it is a generic solution. I think the complete lists of tweaks to JFFS2 that I've had to do are: - add option to disable compression. Saves ram. Flash is "cheap". - allow JFFS2 to write to image when there are 0 free sectors. Allows "ROM" scheme above + it fixes bugs that showed up in stress testing of the 6x64k JFFS2 configuration image. - GCC bug-fix. (Now comitted to eCos CVS, I think). - Reboot after a couple of writes to JFFS2 to free up ram. Øyvind -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss