On 03/07/2018 12:18 AM, Pavel Machek wrote: > Now... Yes, handling flash is hard, MLC NAND is worst of the > bunch. But... > MLC is not just more flimsy than SLC NAND.
The real problem is that on MLC NAND, pages come in pairs. Multiple voltage levels inside a single, physical memory cell are used to encode more than one bit. Instead of just having pages that are twice as big, the flash exposes them as *two different pages*. Those pages are usually not ordered sequentially either, but according to a vendor/device specific pairing scheme. > Read disturb is not unique to MLC, right? Happens to all the flashes, > its just that MLC has tighter margins for error. > You don't just have more read disturb on a single page. Reading one page will also affect the paired page as well.[0] In addition to that, you also have program disturb. Even *writing successfully* to the upper page of a pair also causes bit flips on the lower one, affecting completely different data.[0] This could be addressed using the experimental ubihealthd that crawls the flash from time to time (at UBI level), making UBI notice and fix bit flips.[0] > Power-cut. UBIFS is just not power-cut safe, right? My notes say that > power-cut during erase could result in flash that contains all 1s, but > will start showing errors very quickly. Again, not MLC specific. Can > be solved with battery... > > (And yes, there are some problems specific to MLC, where parts of page > need to be written in specific order. Not sure how it affects > ubifs. But it was not listed as a reason for the patch.) > Both UBI and UBIFS were designed to be power cut tolerant.[1] On MLC however, if you interrupt a write access to the upper page of a pair, you will also corrupt the lower one, i.e. *data that was already written*, which is a serious issue.[0] Richard and Boris did spend a lot of time working on a solution for that at UBI level which would currently still require a lot of testing and fine tuning, but sadly we ran out of budget. The proposed patch tries to prevent further bad surprises for people who try to use UBI and UBIFS on top of MLC by making sure that UBI _refuses_ to run on MLC (at least for now). Regards, David [0] http://linux-mtd.infradead.org/doc/ubifs.html#L_ubifs_mlc [1] http://linux-mtd.infradead.org/doc/ubifs.html#L_powercut
signature.asc
Description: OpenPGP digital signature
