From: Richard Weinberger <richard@nod.at>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Dirk Behme <dirk.behme@de.bosch.com>,
linux-mtd@lists.infradead.org,
boris.brezillon@free-electrons.com,
david.oberhollenzer@sigma-star.at
Subject: Re: [PATCH 0/5] Add flight recorder to MTDRAM
Date: Wed, 06 Dec 2017 20:59:43 +0100 [thread overview]
Message-ID: <1944158.Wp3g4lm68D@blindfold> (raw)
In-Reply-To: <8663ba73-5159-d1ac-5a3b-6d158dcf9923@colorfullife.com>
Manfred,
Am Mittwoch, 6. Dezember 2017, 20:44:55 CET schrieb Manfred Spraul:
> Hi Richard,
>
> On 12/06/2017 11:41 AM, Richard Weinberger wrote:
> > Dirk, Manfred,
> >
> > Am Mittwoch, 6. Dezember 2017, 09:50:34 CET schrieb Dirk Behme:
> >> From: Manfred Spraul <manfred@colorfullife.com>
> >>
> >> Hi,
> >>
> >> The series adds a flight recorder to MTDRAM.
> >
> > Thanks a lot for sharing your tool, this is highly appreciated.
> >
> >> This allows very efficient power fail testing:
> >> From the flight recorder output, it is possible to recreate every image
> >>
> >> that might have existed between the start of the recording and the end.
> >>
> >> Obviously, a user space tool is required, it is attached as the last
> >> mail in the series.
> >
> > So, to understand this approach better I need to recap.
> > The "flight recorder" logs every single MTD operation (READ, ERASE,
> > PROGRAM) to a file while the MTD is under load, right?
>
> Only ERASE and PROGRAM. READ is not logged.
> Would it help if READ is logged as well? (memory is cheap, ...)
>
> What would be fairly simple is to add a backtrace for every ERASE and
> PROGRAM. I'll try to add that.
Given a second thought, for power-cut testing READ is not important.
So no need to hurry.
> > Then you take the log, replay it to a _file_ but instead of replaying
> > all N MTD operations only N - X operations are replayed?
>
> Exactly. Instead of replaying all N operations, only X operations are
> replayed.
>
> image-168167.bin is after replaying 168167 operations.
> image-168168.bin is after replaying one additional operation.
This is what I thought.
It worries me a bit that image-168167.bin shows a corrupted LPT (LEB property
tree). The current logical operation of UBIFS is writing the index tree.
> > The output file is later written back to MTDRAM to check how much UBIFS
> > likes it?
>
> Exactly.
>
> > While having such a tool would be awesome, we have to be very sure that it
> > behaves correctly.
> > Yesterday I spent almost the whole night with staring at some of Manfred's
> > images and I'm not sure whether what I see makes sense or can actually
> > happen on a real NAND or NOR flash. But I'm still investigating.
>
> From my understand, the tool result is exactly identical to a powerfail
> immediately after PROGRAM.
Yes.
> What differs from realistic embedded systems is obviously performance:
> RAM disk+2-core I3 is probably much faster & much more parallelism happens.
Yep. I found also some UBI and UBIFS on my x86 system with nandsim and
powercuts over the last years.
> I have uploaded the initial image, the final image and the flight recording.
>
> https://sourceforge.net/projects/calculix-rpm/files/ubifs/xattr/
Cool! I'll give it a try.
Thanks,
//richard
next prev parent reply other threads:[~2017-12-06 19:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 8:50 [PATCH 0/5] Add flight recorder to MTDRAM Dirk Behme
2017-12-06 8:50 ` [PATCH 1/5] mtdram: expose write size and writebuf size as module parameters Dirk Behme
2017-12-06 8:50 ` [PATCH 2/5] mtdram: Add flight recorder Dirk Behme
2017-12-06 8:50 ` [PATCH 3/5] mtdram: Allow to enable/disable flight recorder mode at runtime Dirk Behme
2017-12-06 8:50 ` [PATCH 4/5] mtdram: Convert the flight recorder to a ring buffer Dirk Behme
2017-12-06 8:50 ` [PATCH 5/5] mtdram flight recorder: Add checksums Dirk Behme
2017-12-06 10:41 ` [PATCH 0/5] Add flight recorder to MTDRAM Richard Weinberger
2017-12-06 19:44 ` Manfred Spraul
2017-12-06 19:59 ` Richard Weinberger [this message]
2017-12-06 20:57 ` Richard Weinberger
2017-12-07 16:06 ` Manfred Spraul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1944158.Wp3g4lm68D@blindfold \
--to=richard@nod.at \
--cc=boris.brezillon@free-electrons.com \
--cc=david.oberhollenzer@sigma-star.at \
--cc=dirk.behme@de.bosch.com \
--cc=linux-mtd@lists.infradead.org \
--cc=manfred@colorfullife.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox