ubifs image file confusion!

[Nancy]

On 5/14/08, Artem Bityutskiy <dedekind at infradead.org> wrote:
> I see. But it is not a good reason for an additional ioctl anyway. In
> Linux we try to keep the amount of ioctl's as low as possible.
   As low as possible, why? As I know Ioctl is a way to make function
spread of device driver. I thought the more Ioctls imply more
functional this device driver has.

> What you can do instead, is to read the volume LEB by LEB, then check
> the data against 0xFFs, and if it contains all 0xFFs - drop this data.
   Is there any choise for me if I do not add this read LEB ioctl to
finish this task?

> What you can do is to save the numbers of dropped LEBs in a file. And
> when you write the dumped image, you feed 0xFFs instead of the LEB which
> were dropped.
>
> For example, you may improve ubiupdatevol and teach it to accept a
> --unmapped=file option which would contain a list of unmapped LEB
> numbers.
How about give each Mapped LEB an header( long long lnum )? So the
image file content structure looks like:
-------------------------------------------------------------------
long long lnum |  LEB |  long long lnum | LEB | ...........................
-------------------------------------------------------------------

And "ubiupdatevol" can do:
1.  erase the volume
2.  write image file to volume, no need to skip the 0xFF

If you agree with this idea, tool mkfs.ubifs, ubinize, ubiupdatevol
should be changed.

For meeting current urgent need ,  ubidumpvol is just for dump FAT
image, cause there's no tools like mkfs.ubifs to generate a FAT image.
I have not enought knowlege to build tool like that. There are many
other filesystem may run on top of this ubiblk device layer.  It's
better to build a general tool like ubidumpvol to do this job to avoid
various differences of filesystem.

-- 
Best wishes,
Nancy