Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753374Ab2HBRgB (ORCPT ); Thu, 2 Aug 2012 13:36:01 -0400 Received: from mga02.intel.com ([134.134.136.20]:39799 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751115Ab2HBRgA (ORCPT ); Thu, 2 Aug 2012 13:36:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="asc'?scan'208";a="180833566" Message-ID: <1343929200.25013.197.camel@sauron.fi.intel.com> Subject: Re: UBI fastmap updates From: Artem Bityutskiy Reply-To: artem.bityutskiy@linux.intel.com To: Tim Bird Cc: Richard Weinberger , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "adrian.hunter@intel.com" , "Heinz.Egger@linutronix.de" , "thomas.wucher@linutronix.de" , "shmulik.ladkani@gmail.com" , "tglx@linutronix.de" , "Marius.Mazarel@ugal.ro" , "nyoushchenko@mvista.com" Date: Thu, 02 Aug 2012 20:40:00 +0300 In-Reply-To: <501AB2C8.9010805@am.sony.com> References: <1341836323-43916-1-git-send-email-richard@nod.at> <1343916747.25013.112.camel@sauron.fi.intel.com> <20120802161512.5ac7a303@spider.haslach.nod.at> <1343917741.25013.114.camel@sauron.fi.intel.com> <20120802165132.1bf1e5d7@spider.haslach.nod.at> <1343924267.25013.156.camel@sauron.fi.intel.com> <20120802183210.7076aa48@spider.haslach.nod.at> <1343925930.25013.163.camel@sauron.fi.intel.com> <501AB2C8.9010805@am.sony.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SX9v6z9FZTOzHDZvr2e0" X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4703 Lines: 117 --=-SX9v6z9FZTOzHDZvr2e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tim, On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote: > I'm don't understand what "UBI liability" is. Can you please clarify? > What breaks if the PEBs get consumed? let me try. Let's forget about bad blocks and assume we are talking about NOR flash. For simplicity. Let's also first forget about fastmap so far and talk about the current design. Suppose you have 100 PEBs on your flash. Suppose UBI reserves 10 for its internal needs (volume table, etc). 90 PEBs are available to the user. User now can create one or many volumes, but the overall size of the volumes cannot be larger than 90 LEBs. This means that UBI guarantees that you can always fill all volumes with data there will always be enough PEBs to map to. This is UBI liability. UBI will not allow you to create a volume of 100 LEBs because in this case it will not be able to guarantee that all LEBs will be writable. I have invented this "liability" term on the spot actually. It basically means what UBI already "promised", what it reserved an put aside. Now let's add fastmap support to the picture. Suppose fastmap took another 10 PEBs and now we have 80 PEBs for the user. The user can create a volume of 80 LEBs in size. And UBI has to guarantee that the user can at any point of time fill all of them with data. This means that fastmap in no circumstances can grab any more than 10 PEBs, because they are all reserved, UBI liability is 80 PEBs. On other words, fastmap has to know how much PEBs it needs at the UBI initialization time, and reserve them. The _maximum_ value. The same way other UBI sub-systems do. E.g., the volume table code reserves 2 PEBs, because this is the maximum it needs at any point of time. The WL subsystem reserves 1 PEB. Of course this is not about reserving any specific PEB, this is just accounting - we have a couple of variable for reserved PEBs count. So let's return to the error messages I spotted. They say that fastmap needs a PEB but cannot find one. The flash is nandsim and has no badblocks. Why fastmap did not find one? Because it did not reserve enough. And UBI tests create volumes of maximum possible size and fill it with data, so all available PEBs are mapped and thus, used. What this means that the following situation is possible: the UBI volume is not fully filled yet and not all LEBs are mapped, so there are available PEBs, and fastmap successfully grows and reduces the amount of available PEBs. And when the user writes more data, he gets -ENOSPC. And this is basically the problem I indicated. To make my description complete, let's add NAND to the picture. We simply reserve 2% (by default, it is configurable) of PEBs for bad blocks handling. This is because vendors typically say that this is the maximum amount for the flash life-time. If NAND wears-out a lot, and we run out of reserved PEBs, we switch to R/O mode, because we cannot anymore keep our "promise", the liability. You can look at it this way. If you create an UBI volume, and mount it with UBIFS, you usually expect that all the free file-system space is available to you. You probably will be disappointed if you write your file and get -ENOSPC because fastmap does grew and consumed a PEB which which was promised to your volume. --=20 Best Regards, Artem Bityutskiy --=-SX9v6z9FZTOzHDZvr2e0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJQGrtwAAoJECmIfjd9wqK0ADwP/jrPY3wUfe+BLiFmOT02D9Ge EDmiWbxcwPUAxf+qQ2IWJDbaXVVYjKSJg+5Sord/TIMOae0cn5MDzoinl5eQ3jjb K1w81j7TBKDwCFI67lv3hvJc2G1ZqM5CVLm3Ie20m0X5Vn7FUwfHIQqAs5MF5y1b ls5DS/e48xf42kmTKHX3FQjj6cc2DLA37aHnkswsF1kkDRSAenXUF6+YFqxjavUp pHmxOfbRHmEtdNFHBc4/uT9ElTGhTz98r0OlrMybFu8PI5S1VpOMI0a4FEadgLCu AUjxlOCDnoXwJHs7AnwyHtF9c/Hj9JLZp2U2heMj73jsy5S877+c0grJ9frrtX++ jxreZDeDLGkog0Czs+zpV87qznMFNXZaGxtmheY6ueMVBOgqgFFAxjZxKKvsdwTi S3BgWnFErAEbFjj+ajf8S0voymA41RAOfR2CwO3cg77sHJtYwoQ9s3T87+3aoZ7j j6jXsNlbc3HIOv8coSPCsNDlO1igdDvF2wlhLUwfKymGyC2a1cuDcieZprbCFUxb G70XeHBO2z1iUaWdrUHwndOW3yB49vEbTv6BXFTz2v3Dj2sgSSrtPGk6b18HFRNS hzOvQkW2ozhaVni4UsCm1LbT7Mqn2N1nQfz/wiBpuEkWqt7Ohy9ChuztPIUpyXSo 6AG+CyrjpSJHTkAQn72r =ikuX -----END PGP SIGNATURE----- --=-SX9v6z9FZTOzHDZvr2e0-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/