public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Anatolij Gustschin <agust@denx.de>
To: dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, Detlev Zundel <dzu@denx.de>
Subject: Re: [PATCH] UBIFS: fix master node recovery
Date: Thu, 7 Jul 2011 10:44:48 +0200	[thread overview]
Message-ID: <20110707104448.7f6f0cea@wker> (raw)
In-Reply-To: <1310025429.3149.133.camel@sauron>

On Thu, 07 Jul 2011 10:57:05 +0300
Artem Bityutskiy <dedekind1@gmail.com> wrote:

> On Thu, 2011-07-07 at 09:43 +0200, Anatolij Gustschin wrote:
> > Yes, in our case we have 511 valid master nodes + 384 bytes free
> > space in LEB 2 and one valid master node in LEB 1 + free space.
> > 
> > > What we want to check is that there is no room for another master node
> > > in the second LEB. We have to take offs2, add sz, and make sure that LEB
> > > size minus that is less than sz, i.e., exactly what you have done.
> > > 
> > > And  offs2 + sz >= c->leb_size seems to be completely incorrect and
> > > should be removed, AFAICS. Can you confirm that?
> > 
> > Yes, offs2 + sz >= c->leb_size check is not correct, I think.
> 
> I also think so. Could you send v2 of your patch - kill the incorrect
> check and add your correct check instead.

Thinking more about this I can imagine the situation where
off2 + sz == c->leb_size condition is true (depending on LEB size,
node alignment, etc.), so we should check for this condition also.
off2 + sz > c->leb_size can't be the case since off2 is the offset
of a valid node. So we should check for
off2 + sz == c->leb_size || (c->leb_size - offs2 - sz) < sz.

> I do not have time for testing this now, so I'd ask you go test it. But
> I realize that power cut testing can take a lot of time, and your patch
> looks right to me, so I'm happy to take your patch right away, but I'd
> anyway ask you to conduct some testing anyway and inform about your
> results later.
> 
> BTW, you can try the power cut emulation testing. If you care a lot
> about power-cut robustness, it is helpful. The integck test now can do
> power cut emulation testing with UBIFS. But there still some small
> issues, though.

Thanks,
Anatolij

  reply	other threads:[~2011-07-07  8:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06  9:30 [PATCH] UBIFS: fix master node recovery Anatolij Gustschin
2011-07-07  6:15 ` Artem Bityutskiy
2011-07-07  7:36   ` Anatolij Gustschin
2011-07-07  6:26 ` Artem Bityutskiy
2011-07-07  7:43   ` Anatolij Gustschin
2011-07-07  7:57     ` Artem Bityutskiy
2011-07-07  8:44       ` Anatolij Gustschin [this message]
2011-07-07  8:57         ` Artem Bityutskiy
2011-07-07  9:05           ` Anatolij Gustschin
2011-07-07  9:51 ` [PATCH v2] " Anatolij Gustschin
2011-07-07  9:55   ` Artem Bityutskiy
2011-07-07 10:25   ` [PATCH v3] " Anatolij Gustschin
2011-07-08  3:55     ` Artem Bityutskiy

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=20110707104448.7f6f0cea@wker \
    --to=agust@denx.de \
    --cc=dedekind1@gmail.com \
    --cc=dzu@denx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox