Re: gluebi char vs block devices

[Artem Bityutskiy <dedekind@infradead.org>]

Hi,

On Wed, 2008-10-01 at 09:50 -0500, Monte Copeland wrote:
> Hi,
> 
> What is expected (correct) behavior when reading content of static UBI volumes?
> 
> / # cat /sys/class/ubi/ubi0_6/name
> kernel_0
> / # cat /sys/class/ubi/ubi0_6/data_bytes
> 3149958
> / # cat /dev/mtd/kernel_0 | wc -c
> 3149958
> / # cat /dev/mtdblock/kernel_0 | wc -c
> 3149824
> 
> On my older UBI platform, the byte count from the
> mtdblock dev is truncated down to an even multiple
> of 512.

First of all, gluebi is kind of a hack. Gluebi is a small part of UBI
which is responsible for emulating MTD devices on top of UBI volumes.

Let me describe the situation a little.

* Dynamic UBI volumes have volume size parameter, which maps to
  MTD device size well. I mean, for dynamic volumes, gluebi reports
  MTD device size to be volume size. Everything is fine.

* Static volumes are characterized by 2 parameters - volume size
  and data size. Volume size is how many logical eraseblocks are
  reserved for this volume. Data size is how many bytes of data this
  static volume stores.

For static volumes gluebi reports _data size_ as MTD device size. MTD
model assume that device size is multiple of eraseblocks.But in case of
MTD device emulated on top of a static UBI volume this is not true. MTD
size is not multiple of eraseblock size. And this is what confuses
mtdblock I think.

We cannot report UBI volume size as MTD device size for static volumes,
because reading beyond data size is prohibited in UBI. It would cause
I/O errors for mtd device.

On the other hand, MTD device size which is not multiple of eraseblock
size does not make sense.

So I am not 100% sure how to fix this problem.

Thanks.

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