autoresize causes insufficient reservation of PEBs for bad PEB handling

autoresize causes insufficient reservation of PEBs for bad PEB handling

[Egli, Samuel]

Hi all,

I have difficulties to understand why I get the following warning message
at linux start up:

...
[    4.777488] UBI warning: print_rsvd_warning: cannot reserve enough PEBs \
for bad PEB handling, reserved 40, need 80
...

My assumption is that if I don't specify the size of one volume 
UBI will choose the right size for the volume and reserve the 
right amount of PEBs for bad block handling. With 20/1024 set,vi I
expect indeed to have 80 blocks reserved. But somehow this
does not work. I observed that I get this warning when vol_flags
is set to autoresize. In this case only 40 blocks get reserved.
Using for all volumes the vol_size parameter and omitting 
autoresize, I can avoid this situation and I get my 80 blocks reserved.

However, I don't understand why and it seems odd to me that
autoresize would work this way. 

Can somebody confirm this observations or explain why this
works like this. Maybe I'm also doing something wrong.

See below how I generate the ubi image.

General setup
=============
flash size: 4096 PEBs
mtd partition size: 4065 PEBs
number of volumes: 3

Linux version:
Linux dxr2 3.14.36-r2 #1 PREEMPT Tue Jun 30 10:26:05 CEST 2015 armv7l GNU/Linux


Config 1
========
2 volumes with fixed size
1 volume has vol_flags=autoresize and vol_size not defined

mkfs.ubifs -r ../rootfs/path -o rootfs.ubifs -F -m 2048 -e 126976 -c 4065
mkfs.ubifs -r ../conf/path -o conf.ubifs -F -m 2048 -e 126976 -c 4065
ubinize -o rootfs.ubi -m 2048 -p 131072 -O 2048 ubinize.cfg

ubinize.cfg:
 [rootfs_a]
 mode=ubi
 image=rootfs.ubifs
 vol_id=0
 vol_type=dynamic
 vol_name=rootfs_a
 vol_size=140MiB
 [rootfs_b]
 mode=ubi
 vol_id=1
 vol_type=dynamic
 vol_name=rootfs_b
 vol_size=140MiB
 [configuration]
 mode=ubi
 image=configuration.ubifs
 vol_id=2
 vol_type=dynamic
 vol_name=configuration
 vol_flags=autoresize

--> only 40 blocks get reserved vor bad PEB handling

Config 2
========
All 3 volumes with fixed size

mkfs.ubifs -r ../rootfs/path -o rootfs.ubifs -F -m 2048 -e 126976 -c 4065
mkfs.ubifs -r ../conf/path -o conf.ubifs -F -m 2048 -e 126976 -c 4065

ubinize.cfg:
 [rootfs_a]
 mode=ubi
 image=rootfs.ubifs
 vol_id=0
 vol_type=dynamic
 vol_name=rootfs_a
 vol_size=140MiB
 [rootfs_b]
 mode=ubi
 vol_id=1
 vol_type=dynamic
 vol_name=rootfs_b
 vol_size=140MiB
 [configuration]
 mode=ubi
 image=configuration.ubifs
 vol_id=2
 vol_type=dynamic
 vol_name=configuration
 vol_size=341MiB

--> ok, 80 blocks reserved but cannot use autoresize

Kind ragards

Sam

Re: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Richard Weinberger]

Hi Samuel,

On Mon, Jul 6, 2015 at 1:04 PM, Egli, Samuel <samuel.egli@siemens.com> wrote:
> Hi all,
>
> I have difficulties to understand why I get the following warning message
> at linux start up:
>
> ...
> [    4.777488] UBI warning: print_rsvd_warning: cannot reserve enough PEBs \
> for bad PEB handling, reserved 40, need 80
> ...
>
> My assumption is that if I don't specify the size of one volume
> UBI will choose the right size for the volume and reserve the
> right amount of PEBs for bad block handling. With 20/1024 set,vi I
> expect indeed to have 80 blocks reserved. But somehow this
> does not work. I observed that I get this warning when vol_flags
> is set to autoresize. In this case only 40 blocks get reserved.
> Using for all volumes the vol_size parameter and omitting
> autoresize, I can avoid this situation and I get my 80 blocks reserved.
>
> However, I don't understand why and it seems odd to me that
> autoresize would work this way.
>
> Can somebody confirm this observations or explain why this
> works like this. Maybe I'm also doing something wrong.

I'm a bit puzzled. Can you please share the full kernel log?
Maybe some other UBI warning brings light into that.
Please also share the output of ubinfo -a with and without autoresize.

The re-size mechanism will use ubi->avail_pebs for the new volume size.
ubi->avail_pebs should honor the number of reserved PEBs.
If you have a lot of bad/corrupted PEBs the situation may be different.

-- 
Thanks,
//richard

RE: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Egli, Samuel]

Hi Richard
thank you for your reply.

>-----Original Message-----
>From: Richard Weinberger [mailto:richard.weinberger@gmail.com]
>Sent: Montag, 6. Juli 2015 23:40
>To: Egli, Samuel
>Cc: linux-mtd@lists.infradead.org
>Subject: Re: autoresize causes insufficient reservation of PEBs for bad
>PEB handling
>
>[...]
>
>I'm a bit puzzled. Can you please share the full kernel log?

vol_flags=autoresize
https://gist.github.com/anonymous/7a4b790b27aac81421ab

vol_size fixed
https://gist.github.com/anonymous/811eadc9c6592539387a

>Maybe some other UBI warning brings light into that.
>Please also share the output of ubinfo -a with and without autoresize.

ubinfo -a (vol_flags=autoresize): 
https://gist.github.com/anonymous/44de06911988fb55a742

ubinfo -a (fix vol_size):
https://gist.github.com/anonymous/e5cfbc0a3606d2d35974


>
>The re-size mechanism will use ubi->avail_pebs for the new volume size.
>ubi->avail_pebs should honor the number of reserved PEBs.
>If you have a lot of bad/corrupted PEBs the situation may be different.

Hmm, is there some special handling of SLC and MLC NAND?
Anyway, here the relevant kernel config:

zcat /proc/config.gz | grep UBI:
CONFIG_TCP_CONG_CUBIC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_CRYPTO_ANUBIS is not set

Kind regards

Sam

Re: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Richard Weinberger]

Am 07.07.2015 um 09:57 schrieb Egli, Samuel:
> Hi Richard
> thank you for your reply.
> 
>> -----Original Message-----
>> From: Richard Weinberger [mailto:richard.weinberger@gmail.com]
>> Sent: Montag, 6. Juli 2015 23:40
>> To: Egli, Samuel
>> Cc: linux-mtd@lists.infradead.org
>> Subject: Re: autoresize causes insufficient reservation of PEBs for bad
>> PEB handling
>>
>> [...]
>>
>> I'm a bit puzzled. Can you please share the full kernel log?
> 
> vol_flags=autoresize
> https://gist.github.com/anonymous/7a4b790b27aac81421ab

There are more odds.

I don't see a message like "[   90.757282] ubi0: volume 2 ("configuration") re-sized from 80 to 7948 LEBs"
in that log. So, re-size did not happen.

Is this a pristine kernel or does it contain some vendor "tweaks"?

Thanks,
//richard

RE: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Egli, Samuel]

Hi Richard,

>>> [...]
>>>
>>> I'm a bit puzzled. Can you please share the full kernel log?
>>
>> vol_flags=autoresize
>> https://gist.github.com/anonymous/7a4b790b27aac81421ab
>
>There are more odds.
>
>I don't see a message like "[   90.757282] ubi0: volume 2
>("configuration") re-sized from 80 to 7948 LEBs"
>in that log. So, re-size did not happen.
>
>Is this a pristine kernel or does it contain some vendor "tweaks"?

hmm, thanks for the hint. We have some patches on top of 3.14.36.
Mostly mtd:nand:omap and some other TI patches.

I see to enable some debug prints in ubi to get more information.

Thanks,

Sam


 

RE: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Egli, Samuel]

Hi Richard

>
>There are more odds.
>
>I don't see a message like "[   90.757282] ubi0: volume 2
>("configuration") re-sized from 80 to 7948 LEBs"
>in that log. So, re-size did not happen.
>
>Is this a pristine kernel or does it contain some vendor "tweaks"?

The issue didn't lie in linux kernel. We have in our ubi volume
the uImage. So U-Boot needs to mount it and actually does
the resize. In U-Boot version 2014.04 there is still a 
older ubi driver that doesn't perform the resizing correctly.

With U-Boot v2015.04, however, the issue is resolved.

Thanks, for looking into this.

Sam

Re: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Richard Weinberger]

Am 09.07.2015 um 12:23 schrieb Egli, Samuel:
> Hi Richard
> 
>>
>> There are more odds.
>>
>> I don't see a message like "[   90.757282] ubi0: volume 2
>> ("configuration") re-sized from 80 to 7948 LEBs"
>> in that log. So, re-size did not happen.
>>
>> Is this a pristine kernel or does it contain some vendor "tweaks"?
> 
> The issue didn't lie in linux kernel. We have in our ubi volume
> the uImage. So U-Boot needs to mount it and actually does
> the resize. In U-Boot version 2014.04 there is still a 
> older ubi driver that doesn't perform the resizing correctly.

Bah. ;-\

> With U-Boot v2015.04, however, the issue is resolved.

Thanks for letting me know.

> Thanks, for looking into this.

You're welcome!

Thanks,
//richard

Re: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Richard Weinberger]

Samuel,

On Mon, Jul 6, 2015 at 1:04 PM, Egli, Samuel <samuel.egli@siemens.com> wrote:
> Hi all,
>
> I have difficulties to understand why I get the following warning message
> at linux start up:
>
> ...
> [    4.777488] UBI warning: print_rsvd_warning: cannot reserve enough PEBs \
> for bad PEB handling, reserved 40, need 80
> ...
>
> My assumption is that if I don't specify the size of one volume
> UBI will choose the right size for the volume and reserve the
> right amount of PEBs for bad block handling. With 20/1024 set,vi I
> expect indeed to have 80 blocks reserved. But somehow this
> does not work. I observed that I get this warning when vol_flags
> is set to autoresize. In this case only 40 blocks get reserved.
> Using for all volumes the vol_size parameter and omitting
> autoresize, I can avoid this situation and I get my 80 blocks reserved.
>
> However, I don't understand why and it seems odd to me that
> autoresize would work this way.
>
> Can somebody confirm this observations or explain why this
> works like this. Maybe I'm also doing something wrong.
>
> See below how I generate the ubi image.
>
> General setup
> =============
> flash size: 4096 PEBs
> mtd partition size: 4065 PEBs
> number of volumes: 3
>
> Linux version:
> Linux dxr2 3.14.36-r2 #1 PREEMPT Tue Jun 30 10:26:05 CEST 2015 armv7l GNU/Linux
>
>
> Config 1
> ========
> 2 volumes with fixed size
> 1 volume has vol_flags=autoresize and vol_size not defined
>
> mkfs.ubifs -r ../rootfs/path -o rootfs.ubifs -F -m 2048 -e 126976 -c 4065
> mkfs.ubifs -r ../conf/path -o conf.ubifs -F -m 2048 -e 126976 -c 4065
> ubinize -o rootfs.ubi -m 2048 -p 131072 -O 2048 ubinize.cfg
>
> ubinize.cfg:
>  [rootfs_a]
>  mode=ubi
>  image=rootfs.ubifs
>  vol_id=0
>  vol_type=dynamic
>  vol_name=rootfs_a
>  vol_size=140MiB
>  [rootfs_b]
>  mode=ubi
>  vol_id=1
>  vol_type=dynamic
>  vol_name=rootfs_b
>  vol_size=140MiB
>  [configuration]
>  mode=ubi
>  image=configuration.ubifs
>  vol_id=2
>  vol_type=dynamic
>  vol_name=configuration
>  vol_flags=autoresize
>
> --> only 40 blocks get reserved vor bad PEB handling
>
> Config 2
> ========
> All 3 volumes with fixed size
>
> mkfs.ubifs -r ../rootfs/path -o rootfs.ubifs -F -m 2048 -e 126976 -c 4065
> mkfs.ubifs -r ../conf/path -o conf.ubifs -F -m 2048 -e 126976 -c 4065
>
> ubinize.cfg:
>  [rootfs_a]
>  mode=ubi
>  image=rootfs.ubifs
>  vol_id=0
>  vol_type=dynamic
>  vol_name=rootfs_a
>  vol_size=140MiB
>  [rootfs_b]
>  mode=ubi
>  vol_id=1
>  vol_type=dynamic
>  vol_name=rootfs_b
>  vol_size=140MiB
>  [configuration]
>  mode=ubi
>  image=configuration.ubifs
>  vol_id=2
>  vol_type=dynamic
>  vol_name=configuration
>  vol_size=341MiB

Something I did not notice yesternight, 140+140+341 is 621.
According to your logs the MTD partition is only 508MiB large.

-- 
Thanks,
//richard

RE: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Egli, Samuel]

Hello Richard,

>-----Original Message-----
>From: Richard Weinberger [mailto:richard.weinberger@gmail.com]
>Sent: Dienstag, 7. Juli 2015 12:50
>To: Egli, Samuel
>Cc: linux-mtd@lists.infradead.org
>Subject: Re: autoresize causes insufficient reservation of PEBs for bad
>PEB handling
>
>Samuel,
>
>On Mon, Jul 6, 2015 at 1:04 PM, Egli, Samuel <samuel.egli@siemens.com>
>wrote:
>> Hi all,
>>
>> I have difficulties to understand why I get the following warning
>> message at linux start up:
>>
>> ...
>> [    4.777488] UBI warning: print_rsvd_warning: cannot reserve enough
>PEBs \
>> for bad PEB handling, reserved 40, need 80 ...
>>
>> My assumption is that if I don't specify the size of one volume UBI
>> will choose the right size for the volume and reserve the right amount
>> of PEBs for bad block handling. With 20/1024 set,vi I expect indeed to
>> have 80 blocks reserved. But somehow this does not work. I observed
>> that I get this warning when vol_flags is set to autoresize. In this
>> case only 40 blocks get reserved.
>> Using for all volumes the vol_size parameter and omitting autoresize,
>> I can avoid this situation and I get my 80 blocks reserved.
>>
>> However, I don't understand why and it seems odd to me that autoresize
>> would work this way.
>>
>> Can somebody confirm this observations or explain why this works like
>> this. Maybe I'm also doing something wrong.
>>
>> See below how I generate the ubi image.
>>
>> General setup
>> =============
>> flash size: 4096 PEBs
>> mtd partition size: 4065 PEBs
>> number of volumes: 3
>>
>> Linux version:
>> Linux dxr2 3.14.36-r2 #1 PREEMPT Tue Jun 30 10:26:05 CEST 2015 armv7l
>> GNU/Linux
>>
>>
>> Config 1
>> ========
>> 2 volumes with fixed size
>> 1 volume has vol_flags=autoresize and vol_size not defined
>>
>> mkfs.ubifs -r ../rootfs/path -o rootfs.ubifs -F -m 2048 -e 126976 -c
>> 4065 mkfs.ubifs -r ../conf/path -o conf.ubifs -F -m 2048 -e 126976 -c
>> 4065 ubinize -o rootfs.ubi -m 2048 -p 131072 -O 2048 ubinize.cfg
>>
>> ubinize.cfg:
>>  [rootfs_a]
>>  mode=ubi
>>  image=rootfs.ubifs
>>  vol_id=0
>>  vol_type=dynamic
>>  vol_name=rootfs_a
>>  vol_size=140MiB
>>  [rootfs_b]
>>  mode=ubi
>>  vol_id=1
>>  vol_type=dynamic
>>  vol_name=rootfs_b
>>  vol_size=140MiB
>>  [configuration]
>>  mode=ubi
>>  image=configuration.ubifs
>>  vol_id=2
>>  vol_type=dynamic
>>  vol_name=configuration
>>  vol_flags=autoresize
>>
>> --> only 40 blocks get reserved vor bad PEB handling
>>
>> Config 2
>> ========
>> All 3 volumes with fixed size
>>
>> mkfs.ubifs -r ../rootfs/path -o rootfs.ubifs -F -m 2048 -e 126976 -c
>> 4065 mkfs.ubifs -r ../conf/path -o conf.ubifs -F -m 2048 -e 126976 -c
>> 4065
>>
>> ubinize.cfg:
>>  [rootfs_a]
>>  mode=ubi
>>  image=rootfs.ubifs
>>  vol_id=0
>>  vol_type=dynamic
>>  vol_name=rootfs_a
>>  vol_size=140MiB
>>  [rootfs_b]
>>  mode=ubi
>>  vol_id=1
>>  vol_type=dynamic
>>  vol_name=rootfs_b
>>  vol_size=140MiB
>>  [configuration]
>>  mode=ubi
>>  image=configuration.ubifs
>>  vol_id=2
>>  vol_type=dynamic
>>  vol_name=configuration
>>  vol_size=341MiB
>
>Something I did not notice yesternight, 140+140+341 is 621.
>According to your logs the MTD partition is only 508MiB large.

oops. Sorry, this is my mistake. We have to products with same 
number of volumes and names but with different volume sizes.

The samples I linked on gist have vol_size for rootfs_a and 
rootfs_b set to 70MiB. So when setting the 3rd vol_size to
341MiB I get like linked before from "ubinfo -a" the following:

ubi0
Volumes count:                           3
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     4065 (516157440 bytes, 492.2 MiB)
Amount of available logical eraseblocks: 7 (888832 bytes, 868.0 KiB)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  80
Current maximum erase counter value:     2
Minimum input/output unit size:          2048 bytes
Character device major/minor:            251:0
Present volumes:                         0, 1, 2
 
Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        579 LEBs (73519104 bytes, 70.1 MiB)
State:       OK
Name:        rootfs_a
Character device major/minor: 251:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        579 LEBs (73519104 bytes, 70.1 MiB)
State:       OK
Name:        rootfs_b
Character device major/minor: 251:2
-----------------------------------
Volume ID:   2 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2816 LEBs (357564416 bytes, 341.0 MiB)
State:       OK
Name:        configuration
Character device major/minor: 251:3

So this is actually ok. I get my 80 blocks reserved.

Sorry for the confusion.

Sam

Re: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Richard Weinberger]

Am 07.07.2015 um 12:59 schrieb Egli, Samuel:
> Hello Richard,
>> Something I did not notice yesternight, 140+140+341 is 621.
>> According to your logs the MTD partition is only 508MiB large.
> 
> oops. Sorry, this is my mistake. We have to products with same 
> number of volumes and names but with different volume sizes.
> 
> The samples I linked on gist have vol_size for rootfs_a and 
> rootfs_b set to 70MiB. So when setting the 3rd vol_size to
> 341MiB I get like linked before from "ubinfo -a" the following:
> 
> ubi0
> Volumes count:                           3
> Logical eraseblock size:                 126976 bytes, 124.0 KiB
> Total amount of logical eraseblocks:     4065 (516157440 bytes, 492.2 MiB)
> Amount of available logical eraseblocks: 7 (888832 bytes, 868.0 KiB)
> Maximum count of volumes                 128
> Count of bad physical eraseblocks:       0
> Count of reserved physical eraseblocks:  80
> Current maximum erase counter value:     2
> Minimum input/output unit size:          2048 bytes
> Character device major/minor:            251:0
> Present volumes:                         0, 1, 2
>  
Richard Weinberger <richard.weinberger@gmail.com>> Volume ID:   0 (on ubi0)
> Type:        dynamic
> Alignment:   1
> Size:        579 LEBs (73519104 bytes, 70.1 MiB)
> State:       OK
> Name:        rootfs_a
> Character device major/minor: 251:1
> -----------------------------------
> Volume ID:   1 (on ubi0)
> Type:        dynamic
> Alignment:   1
> Size:        579 LEBs (73519104 bytes, 70.1 MiB)
> State:       OK
> Name:        rootfs_b
> Character device major/minor: 251:2
> -----------------------------------
> Volume ID:   2 (on ubi0)
> Type:        dynamic
> Alignment:   1
> Size:        2816 LEBs (357564416 bytes, 341.0 MiB)
> State:       OK
> Name:        configuration
> Character device major/minor: 251:3
> 
> So this is actually ok. I get my 80 blocks reserved.
> 
> Sorry for the confusion.

Okay. So there is no issue at all? :-)

Thanks,
//richard

RE: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Egli, Samuel]

Hi Richard,

>-----Original Message-----
>From: Richard Weinberger [mailto:richard@nod.at]
>Sent: Dienstag, 7. Juli 2015 13:05
>To: Egli, Samuel
>Cc: linux-mtd@lists.infradead.org
>Subject: Re: autoresize causes insufficient reservation of PEBs for bad
>PEB handling
>
>[...]
>>
>> So this is actually ok. I get my 80 blocks reserved.
>>
>> Sorry for the confusion.
>
>Okay. So there is no issue at all? :-)

Well, in my opinion it is a workaround to define all 3 vol_size's
But I would like to use the "autoresize" flag for the 3rd volume. 
And I'm just worried that something else is not working properly 
because I think it should work also with autoresize. 

I was also checking to modify the ubifs parameters.

Initially I thought, that max leb count should have the size of my
mtd partition, i.e. 4056. Reading the documentation I understood,
that you can limit the space the image will take. So tried to limit
it to 2827 (4065 - 2*579 - 80) LEBs. But this didn't help either.

e.g.

mkfs.ubifs -r ../conf/path -o conf.ubifs -F -m 2048 -e 126976 -c 2827

Thanks,
Sam

Re: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Richard Weinberger]

Am 07.07.2015 um 13:19 schrieb Egli, Samuel:
> Hi Richard,
> 
>> -----Original Message-----
>> From: Richard Weinberger [mailto:richard@nod.at]
>> Sent: Dienstag, 7. Juli 2015 13:05
>> To: Egli, Samuel
>> Cc: linux-mtd@lists.infradead.org
>> Subject: Re: autoresize causes insufficient reservation of PEBs for bad
>> PEB handling
>>
>> [...]
>>>
>>> So this is actually ok. I get my 80 blocks reserved.
>>>
>>> Sorry for the confusion.
>>
>> Okay. So there is no issue at all? :-)
> 
> Well, in my opinion it is a workaround to define all 3 vol_size's
> But I would like to use the "autoresize" flag for the 3rd volume. 
> And I'm just worried that something else is not working properly 
> because I think it should work also with autoresize. 

Ah, I thought the issue is gone. But you still get the error
that UBI wants 80 PEBs, but gets only 40?

Thanks,
//richard

RE: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Egli, Samuel]

>>
>> Well, in my opinion it is a workaround to define all 3 vol_size's But
>> I would like to use the "autoresize" flag for the 3rd volume.
>> And I'm just worried that something else is not working properly
>> because I think it should work also with autoresize.
>
>Ah, I thought the issue is gone. But you still get the error that UBI
>wants 80 PEBs, but gets only 40?
>
That's correct. When I use "autoresize" flag, independently of defining 
the vol_size of the configuration volume, it will reserve only 40 PEBs 
instead of 80 when mounting the first time.

Re: autoresize causes insufficient reservation of PEBs for bad PEB handling

[Richard Weinberger]

Am 07.07.2015 um 13:27 schrieb Egli, Samuel:
>>>
>>> Well, in my opinion it is a workaround to define all 3 vol_size's But
>>> I would like to use the "autoresize" flag for the 3rd volume.
>>> And I'm just worried that something else is not working properly
>>> because I think it should work also with autoresize.
>>
>> Ah, I thought the issue is gone. But you still get the error that UBI
>> wants 80 PEBs, but gets only 40?
>>
> That's correct. When I use "autoresize" flag, independently of defining 
> the vol_size of the configuration volume, it will reserve only 40 PEBs 
> instead of 80 when mounting the first time.

Hm, I'm a bit puzzled because the resize operation happens after the warning
you're facing.
Maybe Artem has an idea, I suspect some tooling issue.

Thanks,
//richard