From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by bombadil.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux)) id 1LUdrk-0002P9-U8 for linux-mtd@lists.infradead.org; Wed, 04 Feb 2009 09:16:19 +0000 Message-ID: <49895FFC.4020600@nokia.com> Date: Wed, 04 Feb 2009 11:29:32 +0200 From: Adrian Hunter MIME-Version: 1.0 To: Brijesh Singh Subject: Re: Regarding UBI scalability References: <31956721.196931233319535527.JavaMail.weblogic@epml10> <1233567078.7085.62.camel@localhost.localdomain> <618F1BB69C6C43C895C260C527C4F159@sisodomain.com> <4986D3F6.5030208@nokia.com> <1233572259.7085.64.camel@localhost.localdomain> <4986D677.3020500@nokia.com> <71cd59b00902021544w594d4acandc0183bc523aafb0@mail.gmail.com> <6b5362aa0902030235t4175ec11re9b6335df558e6a@mail.gmail.com> In-Reply-To: <6b5362aa0902030235t4175ec11re9b6335df558e6a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Amit Kumar Sharma , "linux-mtd@lists.infradead.org" , Corentin Chary List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Brijesh Singh wrote: > On Tue, Feb 3, 2009 at 5:14 AM, Corentin Chary wrote: >> On Mon, Feb 2, 2009 at 12:18 PM, Adrian Hunter >> wrote: >>> Artem Bityutskiy wrote: >>>> On Mon, 2009-02-02 at 13:07 +0200, Adrian Hunter wrote: >>>>> I would suggest an intermediate step. Create UBI2 which is >>>>> similar to UBI but stores eraseblock information in one place, >>>>> instead of at the beginning of each eraseblock. Such an approach >>>>> might be OK up to as much as 64GiB, and would probably perform >>>>> better than a fully scalable version. >>>>> >>>>> Then look at creating UBI3, which is fully scalable. >>>> Yes, I assume UBI2 should store mapping/erasure information in separate >>>> tables, not in each eraseblock. So we should get rid of eraseblock >>>> headers. >>> Yes that is what I meant. You could probably make do with as little as >>> 12 bytes per eraseblock so a 64GiB flash with 512KiB eraseblock size >>> would need 1536KiB table, which could be read in a second or two, so >>> mount time is OK. > > Adrian,to my understanding, this is minimum info needed per physical > erase block... > > Erase count -8 bytes > Lnum -4 bytes > Volume ID -4 byte(Can make it 1 byte for now as > vol limit=128) > Header CRC -4 bytes(Only for static volumes.) > i.e. Minimum 20 bytes. Is there any other way to make it 12? 8 bytes for erase counter is many more than needed i.e. SLC NAND 100,000 - 1,000,000 max. erase cycles MLC NAND 10000 - 10,000 max. erase cycles Leave out the header CRC for dynamic volumes Combine lnum and volume id. Maybe go so far as to pack the information into bit fields like LPT does. i.e. if the flash media only has a million eraseblocks then only 20 bits are needed for lnum. Maybe it is MLC NAND, so say 15 bits for erase counter. That leaves 5 bites for volume id, and fits into 5 bytes for dynmaic volumes. > And how to update the table relatively efficiently? Each update to UBI typically requires writing a whole NAND page. That page can be filled with unchanged information from the first eraseblock of UBI information. Hence after enough updates the first eraseblock will end up containing only out-of-date information and can then be unmapped. Wash, rinse, repeat. > >> Hi, >> I was wondering how it is possible to get atomic operations using such tables ? > May be keeping a commit block and journal will help.(*Like UBIFS design) > > Thanks, > Brijesh >