From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-gy0-f177.google.com ([209.85.160.177]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1O1cgm-0001zZ-6Y for linux-mtd@lists.infradead.org; Tue, 13 Apr 2010 09:45:49 +0000 Received: by gyb11 with SMTP id 11so3528473gyb.36 for ; Tue, 13 Apr 2010 02:45:44 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <980E75202FF04069AAE27686AB103C09@sisodomain.com> References: <5205AB2678D945D194F6372BE9297942@sisodomain.com> <5156D5DBD34A4A5984AE3F3840C0452F@sisodomain.com> <1244813557.3511.1272.camel@macbook.infradead.org> <42F6638D897B4BA7B729CBC244D9F6E4@sisodomain.com> <1245698113.25547.229.camel@macbook.infradead.org> <04513CE719AF46EDACC26900E39ED2F2@sisodomain.com> <980E75202FF04069AAE27686AB103C09@sisodomain.com> Date: Tue, 13 Apr 2010 11:45:43 +0200 Message-ID: Subject: Re: MLC Support in JFFS2 From: massimo cirillo To: Amul Kumar Saha Content-Type: text/plain; charset=ISO-8859-1 Cc: Amit Kumar Sharma , dedekind@infradead.org, apgmoorthy , kyungmin.park@samsung.com, linux-mtd@lists.infradead.org, raghav.gupta@samsung.com, v.dalal@samsung.com, David Woodhouse List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, I agree with you, and the following is my thinking. Let's suppose we have a flash with 2KB page, 128KB block, 4096 blocks (512MB as size of the flash). The cleanmarker would take one page for every block, so the wasted space is 2KB*4096=8MB. Instead if we put the erased info in a single block (TOKEN_BLOCK) we waste only 128KB. But we need to consider the overhead in the management of such a block. We need to store information for 4096 blocks, for example an array of 4096 bit (1=erased, 0=not erased), protected by ECC (against read error) and CRC (against power loss in writing the array on the block). We need 2 pages for each instance of the array. The question is: how often do we need to update this array? If we choose to update each time it is needed (that is when a block is just erased and just before a block is taken from the free list), at the 32nd update we should erase the TOKEN_BLOCK and allocate a new one. IMO this overhead is unacceptable in terms of time performance. So we update the info only at the unmount and when the system is idle. Moreover, there is the problem of power loss between two updates: how to recognize at the mount that the array info is updated? In my opinion the solution is to write an invalidation mark (one page with all zeros) just after the instance of the array when the instance becomes invalid. Bye 2010/4/9 Amul Kumar Saha : > Hi, > > >>Ok, >>but at the remount how do you verify if the TOKEN_BLOCK >>is updated or not (in case of power loss) ? I suggest using >>a commit mark (one page wasted) at the end of the update >>procedure. >>So you'll have in the TOKEN_BLOCK the following layout: >> >>MAGIC_NUMBER of the TOKEN_BLOCK >>ready_to_use info >>commit mark >> >>What do you think ? >> > > Yes. > However, the TOKEN_BLOCK update would then > only be limited to mount and unmount. > As writing a commit mark while the system is still running, > would validate an invalid block on abrupt power-off. > > Regards, > Amul > > >