From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23101 invoked by alias); 29 Jun 2009 11:09:53 -0000 Received: (qmail 23092 invoked by uid 22791); 29 Jun 2009 11:09:52 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from lon1-post-1.mail.demon.net (HELO lon1-post-1.mail.demon.net) (195.173.77.148) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 11:09:43 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by lon1-post-1.mail.demon.net with esmtp (Exim 4.69) id 1MLEk0-0006Kr-Ws; Mon, 29 Jun 2009 11:09:40 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 0892B13877F; Mon, 29 Jun 2009 12:09:38 +0100 (BST) To: Andrew Lunn Cc: "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review References: <4A126D59.7070404@intefo.ch> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> <20090613163115.GN5179@lunn.ch> <20090619074659.GA1188@lunn.ch> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Mon, 29 Jun 2009 11:09:00 -0000 In-Reply-To: <20090619074659.GA1188@lunn.ch> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-06/txt/msg00046.txt.bz2 Andrew Lunn writes: > We don't need to follow the disk driver approach to partitioning. As > Ross said, he used the name "partition" because he could not think of > a better name. However the name does not imply we need to follow the > normal ways for partitions. All we need is a suitable API which is > efficient when used with partitions and without partitions. I wasn't suggesting we follow the disk driver approach. In fact I was using it as an example of an approach that we should not use. > > > I believe that an API that is partition-aware from the start is > > preferable. > > and i prefer an API which works well with and without partitions. Unless I have misunderstood, you appear to be criticizing the eCosCentric design because it makes partitioning an explicit part of the API. My point was that any API that attempts to conceal the presence of partitions will quickly tie iteslf in knots when the need for such things arises. I don't believe that a partition-aware API is particularly high overhead, a handful of extra instructions per API routine and a few extra words per data structure. With a little judicious ifdeffery, it can be almost totally eliminated for the single partition case. To paraphrase Einstein: We should make an API as simple a possible, but not simpler than it needs to be. > Looking at the existing use cases we know about, the systems which > don't need partitions are the ones with the most resource > constrains. Simon does not need partitions, he plans to use a very > lean and mean FS, and only has a small amount of ROM and RAM. With > Ross's API there is the partitions data structure in the HAL, the code > to get this out of the HAL and into the flash library, the extra > function call needed to get a partition handle, and then the checks > used to validate addresses are inside the partition. I've no idea how > much this adds up to in terms of code and data, so i've no idea how > big the overhead is. My contention is that this overhead would be minimal if the NAND system could be configured into a single partition mode. Then, a lot of these checks get collapsed to nothing in the source, or get optimized away by the compiler. > If you have a dedicates partition, sized about right for the kernel, > level wearing brings you nothing. There are no hot blocks in the > kernel image, you replace it all every time. And how often do you > replace the kernel? During development work, maybe quite often, but > once the system is deployed, rarely. What is the typical life of a > block? 10000 erases? A developer may conceivably replace the kernel > 10,000 times, but in a deployed product i doubt this will happen. So i > say forget about wear leveling for this case. Exact figures for NAND reliability are hard to find. The 100,000 erase cycle guarantee often only applies to the first block. My understanding of NAND is that the design of the cells makes them less reliable that NOR cells. Any cell may go bad, or read back invalid, at any time, not just after some predefined number of erase cycles, albeit with lower probability early in the device's lifetime. So software must keep CRCs and handle bad blocks. The manufacturers exploit this existing requirement to raise yield by allowing parts with factory bad blocks to be sold to customers. So, while most of the time you can get away with a simple approach, every so often you will encounter a device that has cells that go bad very quickly. Unless you have a way of working around this, you may end up with an unusable board. > > For me, dynamic partitions make sense. I'm not saying that release 1.0 > needs to have them, we just need to make sure that the design of > release 1.0 is sufficiently flexible that adding dynamic partitions is > just a release 1.1 feature and not a rip the guts out and start again > for release 2.0. I'm less convinced that dynamic partitions are necessary or useful. I don't believe YAFFS, or any other NAND filesystem, can handle its partition being resized or relocated and having the positions of bad blocks change under it feet. The same would apply to any other piece of software that was NAND aware. Without an existing common mechanism for defining partitions in Linux, we have to fall into line with what happens there. The majority of drivers seem to define fixed static blocks. While we could come up with a definition of a partitioning scheme and promote it in the Linux world, experience suggests that this would be something of an uphill struggle. I know people who have spent years trying to get stuff accepted. Your final point is exactly the one I have been trying to make. We should not be jumping in and specifying partitioning mechanisms right now. I think we need to gather more experience with NAND before we do that. Ross's design permits any sort of partioning mechanism to be defined; at present only one, a CDL-based static partitioning, is implemented. I also believe that by making partioning explicit in the API, we keep the design flexible for the future. -- Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071