[PATCH] UBIFS: compute KSA size and store in superblock

[Artem Bityutskiy]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120526/ff50d5ff/attachment.sig>