Unbounded update to a UBI volume

Unbounded update to a UBI volume

[Nam Nguyen]

Hello list,

The argument to IOCVOLUP is the size of the update.  In case of an
update from a stream, such as from a BZip'ed source, this size is
often not known ahead of time.  Is there a way to programmatically
clear the update marker, without having to pad the volume up to its
size, hence saving unnecessary writes?

Thanks,
Nam

Re: Unbounded update to a UBI volume

[hujianyang]

On 2015/2/27 7:30, Nam Nguyen wrote:
> Hello list,
> 
> The argument to IOCVOLUP is the size of the update.  In case of an
> update from a stream, such as from a BZip'ed source, this size is
> often not known ahead of time.  Is there a way to programmatically
> clear the update marker, without having to pad the volume up to its
> size, hence saving unnecessary writes?
> 
> Thanks,
> Nam

Hi Nam,

I don't think we need an additional way to clear the update marker.
I'm not sure of your use case, I think UBI is mostly used for UBIFS.
We use *ubiupdatevol* which updating the UBIFS image across IOCVOLUP
ioctl. The argument of ubiupdatevol must be a valid UBIFS image, not
a compressed file.

You can first decompress the file and then update the volume.

And actually we have three ways to change an existing volume. Ordinary
write, leb change and updatevol. If updatevol is not suitable for you,
you could try another two ways, I think.

I think in most cases, we could use all of these three ways to write
to a volume except of the static volume, we can only use updatevol to
update it. Is there any other exception?

Thanks,
Hu

Re: Unbounded update to a UBI volume

[Artem Bityutskiy]

On Thu, 2015-02-26 at 15:30 -0800, Nam Nguyen wrote:
> Hello list,
> 
> The argument to IOCVOLUP is the size of the update.  In case of an
> update from a stream, such as from a BZip'ed source, this size is
> often not known ahead of time.  Is there a way to programmatically
> clear the update marker, without having to pad the volume up to its
> size, hence saving unnecessary writes?

I guess you'd need to implement a separate interface for this. It would
work a bit differently, and it would not work for static volumes.