From: Richard Weinberger <richard@nod.at>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
linux-mtd@lists.infradead.org
Subject: Re: UBIFS question: Power-cuts after ubifs_leb_unmap()
Date: Mon, 09 Jul 2018 15:11:39 +0200 [thread overview]
Message-ID: <3206844.7NrM75eRyS@blindfold> (raw)
In-Reply-To: <6f88e3c1-4f27-cb59-5ab4-b3553d20ce27@intel.com>
Am Montag, 9. Juli 2018, 14:21:33 CEST schrieb Adrian Hunter:
> On 09/07/18 13:11, Richard Weinberger wrote:
> > Artem, Adrian,
> >
> > While playing with a new UBI/UBIFS test framework I managed to hit this error,
> > with lprops self-checks enabled:
> >
> > [ 2412.268964] UBIFS error (ubi0:0 pid 708): scan_check_cb: bad accounting of
> > LEB 11: free 0, dirty 118072 flags 0x1, should be free 126976, dirty 0
> >
> > LEB 11 is unmapped but LPT still thinks that some data is used,
> > lp->free + lp >dirty < leb-size.
> > Even without lprobs self-checks, the same filesystem will later hit this
> > assertion in ubifs_garbage_collect_leb():
> >
> > ubifs_assert(!list_empty(&sleb->nodes));
> >
> > The assert makes sure that the LEB actually contains nodes.
> > ubifs_garbage_collect_leb() handles the special case lp->free + lp->dirty ==
> > c->leb_size.
> > But not lp->free + lp->dirty < leb-size.
> >
> > Now I'm not sure where to fix that, maybe you can remember some design
> > decisions.
> > 1. Shall we massage ubifs_garbage_collect_leb() to deal with this special case
> > too?
> > 2. Is it already a bug when this case happens?
> >
> >>From reviewing the code, I think the said situation can arise when we face
> > power-cut
> > in ubifs_garbage_collect_leb():
> >
> > if (snod->type == UBIFS_IDX_NODE) {
> > ...
> > } else {
> > ...
> >
> > err = ubifs_change_one_lp(c, lnum, c->leb_size, 0, 0, 0, 0);
> >
> > ...
> >
> > err = ubifs_leb_unmap(c, lnum);
> >
> > // POWER CUT
> > }
> >
> > We mark the LEB as free and unmap it.
> > ubifs_change_one_lp() does not immediately write a new LPT, if we lose power
> > right after ubifs_leb_unmap() it can happen that the LEB already got erased
> > but the LPT has the old accounting information.
>
> Doesn't GC copy the nodes into the journal, so after the journal is
> replayed, the old nodes will be dirtied and lprops will be correct again.
Yes, this is the theory. But the assert proves that something is not as we expect it. ;-\
Thanks,
//richard
next prev parent reply other threads:[~2018-07-09 13:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 10:11 UBIFS question: Power-cuts after ubifs_leb_unmap() Richard Weinberger
2018-07-09 12:21 ` Adrian Hunter
2018-07-09 13:11 ` Richard Weinberger [this message]
2018-07-10 6:58 ` Adrian Hunter
2018-07-24 8:01 ` Artem Bityutskiy
2018-07-25 22:29 ` Richard Weinberger
2018-07-30 6:55 ` Adrian Hunter
2018-07-30 7:28 ` Richard Weinberger
2018-07-30 8:07 ` Adrian Hunter
2018-07-31 21:28 ` Richard Weinberger
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=3206844.7NrM75eRyS@blindfold \
--to=richard@nod.at \
--cc=adrian.hunter@intel.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=linux-mtd@lists.infradead.org \
/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.