public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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