All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Matthew L. Creech" <mlcreech@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2/3] ubifs: add ubifs_mount_fixup_lebs()
Date: Thu, 05 May 2011 14:49:10 +0300	[thread overview]
Message-ID: <1304596150.7222.51.camel@localhost> (raw)
In-Reply-To: <BANLkTimi=Xvvy98aj9u3Gaapzkb3hWSNgQ@mail.gmail.com>

On Wed, 2011-05-04 at 18:02 -0400, Matthew L. Creech wrote:
> All makes sense Artem, thanks for the feedback.
> 
> On Wed, May 4, 2011 at 7:13 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > On Tue, 2011-05-03 at 18:55 -0400, Matthew L. Creech wrote:
> >> +
> >> +             if (!(lprops->flags & LPROPS_EMPTY) &&
> >
> > I think this is not quite right, because empty taken LEBs will not be
> > fixed up. I think you should only look at free space and nothing else.
> >
> 
> OK, however I did find that I needed to check for (lprops->flags &
> LPROPS_TAKEN) in addition to (lprops->free == c->leb_size) before
> unmapping a LEB.  Failing to do so caused this:
> 
> UBIFS error (pid 1): check_lpt_type: invalid type (15) in LPT node type 1
> UBIFS error (pid 1): ubifs_read_nnode: error -22 reading nnode at 8:783
> 
> so apparently it was unmapping part of the LPT, I guess?

Oh, right, the LPT subsystem contains the information about LEBs in the
main area, i.e., from LEBs number c->main_first to LEB number c->leb_cnt
- 1

The area which go _fefore_ the main are are special case.

The lprops area are LEBs from number c->lpt_first to number c->lpt_last.
For those you need to look at the ltab: 

c->ltab[lnum - c->lpt_first].free is what you need, where lnum is the
LEB number you need the amount of free space for.

For the orphans area [c->orph_first, c->orph_last] - you may to just
unmap them all, because when after mount this area does not contain any
useful data.

Master area - LEBs UBIFS_MST_LNUM and UBIFS_MST_LNUM + 1 - you know the
free space start at c->mst_offs + c->mst_node_alsz. So the amount of
used space there is c->mst_offs + c->mst_node_alsz and free space is
c->leb_size - c->mst_offs - c->mst_node_alsz; And it is the same for
both master area LEBs.

And finally the SB area (1 LEB) - you can skip this, but for
consistency, you can also fix it up. Amount of used space there is
always UBIFS_SB_NODE_SZ.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2011-05-05 11:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-03 22:55 [PATCH 2/3] ubifs: add ubifs_mount_fixup_lebs() Matthew L. Creech
2011-05-04 11:13 ` Artem Bityutskiy
2011-05-04 22:02   ` Matthew L. Creech
2011-05-05 11:49     ` Artem Bityutskiy [this message]
2011-05-05 20:36       ` Matthew L. Creech
2011-05-06 14:44         ` 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=1304596150.7222.51.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mlcreech@gmail.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.