Re: jffs2, mtd, mtd-utils and ancient kernels

[don311@xxxxxx]

On Tue, 2019-10-15 21:11:39 +0200, Richard Weinberger wrote:
> On Tue, Oct 15, 2019 at 3:01 AM <don311@xxxxxx> wrote:
> > Q2/ Is there anything you can point me to that shows which versions of
> >     MTD, JFFS2, and mtd-utils were delivered for use with each Linux
> >     kernel release?  In my case, I have particular interest in kernel
> >     2.4.26 -- so would it be possible to, say, find the mtd-utils
> >     version that corresponds to the version of MTD and JFFS2 used in
> >     2.4.26?
>
> Usually Debian is a good source for such an information.
> ...or any other Linux distro with long term archives.

Ah, good idea, I should've thought of this.

They don't make the old stuff real easy to find, but it looks as though
Debian jumped from mtd-tools 20011217-3 in 3.0 (Woody) to 20050122-2 in
3.1 (Sarge) -- quite a big jump.  I also tried Fedora and couple distros
that targeted embedded systems without much luck.  But I can keep
looking.

I just noticed that one of the versions in our source repo is referred
to as 20040219.  That's plausible, considering 2.4.26 was released a
couple months after that.  Still, it would be nice to be able to verify
that the code there matches the original release.

> >       - On the backward side, how dangerous would it be to use a 2.4.26
> >         kernel with a new (never mounted) JFFS2 image built with a later
> >         version of mkfs.jffs2?  ...
>
> As long you don't enable newer features in mkfs, it should work too.

Okay, this is the situation I inherited: JFFS2 images that were
generated with mkfs.jffs2 from ~2012 are being used in production with
target systems running 2.4.26.  To me it was a potential "red flag" from
the start (without knowing any internal details), and discovering that
image files generated by differing versions didn't match didn't make me
feel any better about it.  But I'm glad to hear there are no obvious
incompatibilities.  I'll have to check the command line, but I doubt
we're using any newer features.

> > Q4/ The JFFS2 code in 2.4 is also referred to as well tested.  Is anyone
> >     here aware of whether that extends to the area of random hardware
> >     resets / power cuts, such as might be experienced on embedded
> >     devices without reliable power sources?  I see there were many
> >     performance improvements and bug fixes over the years, but are you
> >     aware of any data about relative reliability -- on the same hardware
> >     -- of JFFS2 in 2.4 vs much later / current, say?  (I believe "on the
> >     same hardware" would imply nor flash here, since 2.4 didn't support
> >     nand.)
>
> You *really* don't want to use a 2.4 kernel.

Very true! :-)

The device I've been hired to work on is used in the building automation
and HVAC industries, where support cycles can run decades, rather than
years (or months) as in many other fields.  Some of the issues I've
fixed have been within the client's own software, but some have been in
the platform -- in custom hardware drivers, for example.  Each one comes
with some sort of calculation of cost (typically my time) and risk,
compared to expected benefit in the field.

In this case, I discovered that a relatively high proportion of
defective units returned from customer sites (that were attributable to
failures in this part of the system) have moderate to severe file system
corruption.  There are many possible explanations, but one of my
theories about it is unfortunate timing of power cuts, relative to file
writes or garbage collection, say.  If this was a known vulnerability of
the otherwise "stable" 2.4 JFFS code, dealing with that would be a high
priority; if not, I'd look elsewhere first.

Moving to a modern kernel, while _very_ appealing in so many ways, is
probably not something that the client would buy into for this
long-obsolete (development-wise) product -- at least not without that
cost-benefit calculation showing that it's an overall win.  I'm not even
sure the core hardware is still supported with modern Linuxes and
toolchains.

So the "pharma" involved here is kind of related to my salary. :-)

Best regards,
Don Estabrook

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/