linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Joel Reardon <joel@clambassador.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UBIFS: compute KSA size and store in superblock
Date: Sat, 26 May 2012 16:31:23 +0300	[thread overview]
Message-ID: <1338039083.2525.27.camel@koala> (raw)
In-Reply-To: <alpine.DEB.2.00.1205261303000.9892@eristoteles.iwoars.net>

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

BTW! While I remember this. You had a concern about bad blocks. I was
thinking that UBI can notify UBIFS every time it marks a block as bad
using the linux notifiers mechanism. UBI would tell UBIFS the volume id
and leb number. Then UBIFS could asynchronously do all the security
stuff which is required in the background thread, or by submitting a
work. I think this is doable, but certainly not a priority.

On Sat, 2012-05-26 at 13:21 +0200, Joel Reardon wrote:
> >
> > I do not have to time to review it now, but please, make sure that the
> > KSA size is according to 'max_leb_cnt' (see the --max-leb-cnt of the
> > mkfs.ubifs tool).
> 
> Ahh, I see now I also need to add the min number of lebs to min_leb_cnt if
> the feature is enabled.

Not sure what you mean...

> > Also, think about this use-case in general: you have
> > UBI volume of size X, then the volume is resized to Y > X, then mounted
> > - UBIFS should work and resize itself to Y, up to the 'max_leb_cnt'. If
> > Y > 'max_leb_cnt', we resize only to 'max_leb_cnt'.
> 
> For this case, it should be fine if the KSA is sized to maxlebcnt.
> However, it will remain that size regardless of the real leb_cnt.

Yes, that's the idea. The lprops area behaves the same. This area stores
a small object for each LEB, so the more LEBs we have, the larger lprops
area is. And 'max_leb_cnt' defines lprops size. We can easily resize up
to 'max_leb_cnt' but re-sizing more than that is currently impossible.

> In general, removing KSA blocks is possible, but if datanodes are
> encrypted with keys on those blocks, then they must be re-encrypted with a
> different key on the smaller set (or somehow write the new last KSA block
> containing all the used keys from the removed KSA blocks along with a
> relocation table, but this seems like alot of coding if removing LEBs from
> the KSA isn't that important.)

Sure, no need to remove. Create them according to 'max_leb_cnt' and
that's it.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-05-26 13:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-25 13:10 [PATCH] UBIFS: compute KSA size and store in superblock Joel Reardon
2012-05-25 13:24 ` Artem Bityutskiy
2012-05-26 11:21   ` Joel Reardon
2012-05-26 13:31     ` Artem Bityutskiy [this message]
2012-05-30 13:32   ` [PATCH v2] " Joel Reardon
2012-05-30 15:18     ` Artem Bityutskiy
2012-05-31 10:12       ` Joel Reardon
2012-05-31 10:19         ` Artem Bityutskiy
2012-05-31 10:36           ` Artem Bityutskiy
2012-06-06 10:03             ` [PATCH v3] " Joel Reardon
2012-06-06 14:30               ` Artem Bityutskiy
2012-06-06 18:52               ` [PATCH v4] " Joel Reardon
2012-06-07  9:06                 ` [PATCH 1/4] UBIFS: correction to Joels' patch Artem Bityutskiy
2012-06-07  9:06                   ` [PATCH 2/4] UBIFS: another correction to joel's patch Artem Bityutskiy
2012-06-07  9:06                   ` [PATCH 3/4] UBIFS: improvement to Joel's patch Artem Bityutskiy
2012-06-07  9:06                   ` [PATCH 4/4] UBIFS: add TOTOs for Joel Artem Bityutskiy
2012-06-07  9:10                 ` [PATCH v4] UBIFS: compute KSA size and store in superblock 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=1338039083.2525.27.camel@koala \
    --to=dedekind1@gmail.com \
    --cc=joel@clambassador.com \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).