All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.