From shivdas.tech@gmail.com Thu Mar 04 18:15:14 2010 Received: from mail-pz0-f203.google.com ([209.85.222.203]) by stoneboat.aleph1.co.uk with esmtp (Exim 4.69) (envelope-from ) id 1NnFZk-0005mF-6L for yaffs@lists.aleph1.co.uk; Thu, 04 Mar 2010 18:15:13 +0000 Received: by pzk41 with SMTP id 41so1888470pzk.23 for ; Thu, 04 Mar 2010 10:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Nz7uoqPsJdBhg9f5IzVbi1lS+IMiBq7d3LIMICTY97U=; b=ECoKRNPYSiS8CpObaZFRviTe9MxVzDMYcztY4lEnNGIvo7PuO7/64FaDv7S/owwJ/m o9AK0tlyd/5TJgTY7TKlSTZNHIk7hQFvwHOgseGkryqQ3+5Igp7B/vHPNyzcwz3VDKl3 jAXCMmK6hnbTrQSbJng/UD4zJgJEJDBosNnZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zw0vI6FSevxBdp/4nk8dDPkBk/O/LKS4uc+p6V7r5hdZtWIWrkHwRNUhlY7z1wB6r+ QSb8Z4caVI08ysIogS4IcDMotETDAFWwpnYs1kFxpSZMNg4Ooe/R47Rb5UlOnFrh03iI JdOootqH43HeHgLqaM3L5G5POeiheDSLq9kAw= MIME-Version: 1.0 Received: by 10.142.209.10 with SMTP id h10mr3260914wfg.278.1267726500119; Thu, 04 Mar 2010 10:15:00 -0800 (PST) In-Reply-To: <201003040934.59743.manningc2@actrix.gen.nz> References: <145446.64911.qm@web29113.mail.ird.yahoo.com> <201003040934.59743.manningc2@actrix.gen.nz> Date: Thu, 4 Mar 2010 10:14:59 -0800 Message-ID: From: Shivdas Gujare To: Charles Manning Content-Type: text/plain; charset=ISO-8859-1 X-SA-Exim-Connect-IP: 209.85.222.203 X-SA-Exim-Mail-From: shivdas.tech@gmail.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-4.2 required=4.5 tests=AWL,BAYES_00,SPF_PASS autolearn=no version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Cc: yaffs@lists.aleph1.co.uk Subject: Re: [Yaffs] Disadvantage of using yaffs checkpointing? X-BeenThere: yaffs@lists.aleph1.co.uk X-Mailman-Version: 2.1.11 Precedence: list List-Id: Discussion of YAFFS NAND flash filesystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 18:15:14 -0000 Hi Charles, Thanks lot for your help. On Wed, Mar 3, 2010 at 12:34 PM, Charles Manning wrote: > On Wednesday 03 March 2010 23:33:31 Sven Van Asbroeck wrote: >> Hello Shivdas, >> >> > So, what does actually "check pointing" saves while >> > unmount? >> >> It's my understanding that the check point consists of the RAM data >> structure which is assembled when a yaffs partition is scanned. It consists >> of meta-information associated with each chunk and block. If you'd like to >> know more, I recommend reading the 'How Yaffs works' document, which is >> available in CVS. > > A full scan builds up a set of data structures that define the file system > state. A checkpoint captures a reduced version of that, enough to > reconstitute the main part of the state and the rest can be built up on a > lazy basis. > >> >> > and Is it >> > safe to use check-pointing always in final product? >> >> According to Charles, checkpointing is designed to be used in the way you >> describe. To my knowledge, no open checkpointing issues exist, but you >> should search the archives. If you are concerned about the checkpoint >> diverging from the meta-information on flash, you could a) disable >> checkpointing altogether, or b) submit a patch implementing a checkpoint >> counter ;-) > > You can also choose to mount ignoring checkpointing with > > mount -t yaffs2 -o"no-checkpoint-read" .. This is not the option for me, since in final product, end user should not be able to change system data (i.e. mount flag's.) Or I can't change it unless rootfs is flashed on device, since yaffs2/nand partitions are mounted from rcS script. Thanks and Regards, Shivdas Gujare . > > -- Charles > > >