On Fri, 2013-03-01 at 15:29 +0100, Richard Genoud wrote: > > Unfortunately I have no additional information why it happened, but > anyway is it really necessary to runs ubiformat+ubimkvol for such > cases? Or is it possible to recover data? > I honestly don't know, but I'm sure Artem has some idea on that.
Everything should work in theory. If there are issues, they should be looked at and investigated. I do not have any better suggestion off the top of my head. > >Since my solution for this case is to put the device data in separate MTD > >with one single UBI volume. But you know how much space I should reserve on > >NAND MTD for single XML-File with 200Bytes :-). > I've got the same problem with uboot environment for example. It's > only some hundred bytes, and still I have to reserve the maximum bad > blocks number + 1 for the environment itself (so for your device 41). > I know, this looks overkill... > For 200bytes, I would try to store them elsewhere (spi dataflash, > eeprom...) if there's such devices on your board. > There's also the 1st block of the nand device which is guaranteed to > be "valid" for 1000 erase cycles (valid with 1-bit ECC per 528 bytes) The ideal solution would be to not partition the chip at all, of course. BTW, if we ara talking about a device for medicine with tens of years of lifetime, you need to be careful about read disturb issues. In the MTD web site we discuss them - and there is a suggestion to read whole UBI device from time to time to force scrubbing. > > Alternative is to try to mount only device volume, copy data in tmpfs, run > > ubiformat+ubimkvol+mount and copy the data back to the device volume. Or > > you have other idea? Not sure why this would be needed. We did not do any on-flash format breakage AFAIK. But I admit I did not read this thread carefully. Sergey, feel free to ask specific questions in separate threads, to make it easier to answer them. -- 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/
