Messages in this thread | | | Subject | Re: Bug in mtd_get_device_size()? | From | Artem Bityutskiy <> | Date | Mon, 11 Mar 2013 10:08:51 +0200 |
| |
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
| |