On Sun, 2007-03-25 at 22:08 +0200, Jörn Engel wrote: > And there is no fundamental reason why UBI should export blocks with > non-power-of-two sizes.
False. There is. > UBI currently consists of two parts that are > intimately intertwined in the current implementation, but have > relatively little connection otherwise. False. They do have connection. > 1. Logical volume management. > 2. Static volumes. > > Logical volume management can just as easily move its management > information into a table, instead of having it spread across all blocks. > Blocks can keep their original size. Since you have to scan flash > anyway, you can also scan for a table, compare a magical number and do > some extra check to protect yourself against a UBI image inside some > logical volume. No big deal. First off, I see these no big deal statements for years already, and no decent implementation proved by usage in real world. Could we please, move these academic discussions to another thread? Second, it is much more robust to kip erase counter and mapping information on per-eraseblock basis then to keep any on-flash table - you may always scan whole media and gracefully recover from errors and corruptions. And you do not loose use a lot in case of corruptions. Third, it is much simpler then keeping any on-flash table, it is thus robust. We do not need a journal to update any table. Third, if needed, on-flash table may be _added_ to increase scalability, so "since you have to scan flash anyway" may become false when there is real need in better scalability. For now scanning is OK. And still, scanning method will be a good fall-back way to recover from errors. > UBI is just as broken as LogFS is. It works with every user in mainline > (which comes down to JFFS2). LogFS works with every MTD device in > mainline. The only combination that doesn't work is LogFS on UBI - due > to deliberate design decisions on both sides. You are welcome to discuss other irrelevant things to this thread. -- Best regards, Artem Bityutskiy (Битюцкий Артём) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
