ubifs image file confusion!

ubifs image file confusion!

[Nancy]

Hi,
   ubifs image size aligned to LEB size. so it contains LEBs from 0 to
?(no matter what the number is). Do all those LEBs mapped in EBA
table?
   My current tool ubidumpvol works fine with VFAT volume( the dumpped
vfat.img can be used by ubiupdatevol and update successful ), but
can't do the same thing to UBIFS volume, the dumpped UBIFS volume size
is 3 LEBs size less then the one generated by mkfs.ubifs.
   When flasher done its job, then the product has to take many other
software test, during the test process, all volumes mount ReadOnly,
then finally every volume's content should have a CRC check. Just need
fix ubidumpvol a little to do the job (read LEB from 0 to ? and count
CRC, compare with the CRC sum generated from the image file)


-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Nancy]

pls:

#ubiupdate /dev/ubi0_0 ubifs.dp   (generated by ubidumpvol)

# mount -t ubifs ubi0:ubifs /mnt/1
UBIFS: mounted UBI device 0, volume 0
UBIFS: minimal I/O unit size:   2048 bytes
UBIFS: logical eraseblock size: 258048 bytes (252 KiB)
UBIFS: file system size:        102445056 bytes (100044 KiB, 97 MiB, 397 LEBs)
UBIFS: journal size:            9420800 bytes (9200 KiB, 8 MiB, 37 LEBs)
UBIFS: data journal heads:      1
UBIFS: default compressor:      LZO
UBIFS error (pid 598): ubifs_check_node: bad magic 0xffffffff, expected 0x610181
UBIFS error (pid 598): ubifs_check_node: bad node at LEB 143:189920
Call Trace:
[<8001fbbc>] dump_stack+0x8/0x34
[<c0152eac>] ubifs_check_node+0x240/0x330 [ubifs]
[<c015312c>] ubifs_read_node+0x190/0x39c [ubifs]
[<c0155268>] load_znode+0xb8/0x78c [ubifs]
[<c01565ac>] lookup_level0+0x260/0x280 [ubifs]
[<c0159ec4>] ubifs_tnc_lookup+0x58/0x16c [ubifs]
[<c0172860>] ubifs_read_inode+0x7c/0x52c [ubifs]
[<c01727a4>] ubifs_iget+0x64/0xa4 [ubifs]
[<c014a924>] ubifs_get_sb+0x19fc/0x1cb8 [ubifs]
[<800ae1f4>] vfs_kern_mount+0x64/0x10c
[<800ae2f8>] do_kern_mount+0x4c/0x134
[<800ce5c0>] do_mount+0x1c0/0x6e4
[<800ceb7c>] sys_mount+0x98/0xfc
[<80021df0>] stack_done+0x20/0x3c

UBIFS error (pid 598): ubifs_read_node: expected node type 9
UBIFS error (pid 598): ubifs_read_inode: failed to read inode 1, error -135
UBIFS: un-mount UBI device 0, volume 0
mount: mounting ubi0:ubifs on /mnt/1 failed: Not a directory

-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Artem Bityutskiy]

On Thu, 2008-05-08 at 17:17 +0800, Nancy wrote:
>    ubifs image size aligned to LEB size.
Right.

>  so it contains LEBs from 0 to
> ?(no matter what the number is).
OK.

>  Do all those LEBs mapped in EBA
> table?
When you flash the image, yes, the will be.

>    My current tool ubidumpvol works fine with VFAT volume
I have no idea what VFAT volume mean. I have not idea what your "current
tool" is. And the rest of your mail is unclear and cryptic for me.

It is very difficult to realize what is the question an the problem from
this mail. Could you please think more on your questions and how you
formulate them? It will help us answering them. Moreover, a well
formulated question already has half an answer.

Thanks.

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

Re: ubifs image file confusion!

[Nancy]

On 5/8/08, Artem Bityutskiy <dedekind@infradead.org> wrote:
> >    My current tool ubidumpvol works fine with VFAT volume
> I have no idea what VFAT volume mean.
VFAT volume means an UBI volume which is managed by VFAT file system.
Current UBI do not have block device layer to support traditional file
system. I have implement one. Not so elegant code, also few comments,
not do code clean. If you need it to solve this problem. OK, I plase
it here.

>I have not idea what your "current tool" is.
please refer to  "[patch]new-ubi-util: ubidumpvol" which I just sent to ML

> It is very difficult to realize what is the question an the problem from
> this mail. Could you please think more on your questions and how you
> formulate them? It will help us answering them. Moreover, a well
> formulated question already has half an answer.
I'm sorry for my careless and bad expression.

To make it simple, short, go to straight:
Normally, if you do
#ubiupdatevol /dev/ubi0_0 ubifs.img (generated by mkfs.ubifs)
then do
#ubidumpvol /dev/ubi0_0 vol0.img
vol0.img and ubifs.img should be exactly the same! But the fact is no!
#ubiupdatevol /dev/ubi0_0 vol0.img
#mount -t ubifs ubi0:ubifs /mnt/1
mount failed, the error message which I already sent before.


Let's see the VFAT volume:
#mkfs.vfat /dev/ubiblock1
#mount -t vfat /dev/ubiblock1 /mnt/1
cp data to /mnt/1
#umount /mnt/1
#ubidumpvol /dev/ubi0_1 vfat.img
#ubiupdatevol /dev/ubi0_1 vfat.img -t
#ubiupdatevol /dev/ubi0_1 vfat.img
#mount -t vfat /dev/ubiblock1 /mnt/1
successful! And all the data is completely fine.

Same tool, same process!
I wonder what's the internal organizeation of ubifs.img(generated by
mkfs.ubifs).
You said ubifs.img is composed of LEBs (from leb 0 to ? what ever the
final logic block number is) and the logical block number keep
increase. If it is like this, there should be no problem for
ubidumpvol goes right, but the practice say no.

Will you please help to figure this problem out? Thanks in advance!

-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Nancy]

Hi Artem,
       ubifs.img (generated by mkfs.ubifs) do contained unmapped LEBs.
       #ubiupdatevol /dev/ubi0_0 ubifs.img   also write the unmapped
LEBs to Nand flash.
       Oh, There should have the same problem like I use nandwrite to
write UBI image to Nand. But the practice tells everything is OK.
Maybe during my test, do not touch the unmapped LEBs. But....weird,
should be have the same problem.

   1,
       when I do
       #ubiupdatevol /dev/ubi0_0 ubifs.img
       #mount -t ubifs ubi0:ubifs /mnt/1
       #rm /mnt/1/* -rf
       #df
       The  ubi0:ubifs Use% is not 0%, but 1%

       But,
       #ubiupdatevol /dev/ubi0_0 ubifs.img -t
       #mount -t ubifs ubi0:ubifs /mnt/1
       #cp data ........
       #umount /mnt/1
       #mount -t ubifs ubi0:ubifs /mnt/1
       #rm /mnt/1/* -rf
       #df
       The ubi0:ubifs Use% is 0%, correct!

       Maybe is the ubiupdatevol write unmapped LEB caused!

    2,
       When I want to earse a volume, I can not do
       #ubiupdatevol /dev/ubi0_0 -t     As what the ubiuptodate -h
Example 2 shows
       ubiupdatevol: error!: specify UBI device name and image file
name as first 2 par
ameters (use -h for help)
       but
       #ubiupdatevol /dev/ubi0_0 ubifs.img -t
       instead, even the function do not need an input image file


-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Nancy]

On 5/10/08, Nancy <nancydreaming@gmail.com> wrote:
> Hi Artem,
>       ubifs.img (generated by mkfs.ubifs) do contained unmapped LEBs.
>       #ubiupdatevol /dev/ubi0_0 ubifs.img   also write the unmapped
> LEBs to Nand flash.
>       Oh, There should have the same problem like I use nandwrite to
> write UBI image to Nand. But the practice tells everything is OK.
> Maybe during my test, do not touch the unmapped LEBs. But....weird,
> should be have the same problem.
>
Sorry, I do not dig deeply, write_leb() skip write the unmapped LEBs to Nand.

I think UBIFS will reserved some logic block number for interal use.
To keep a simple logic to build tool like ubiupdatevol
ubifs.img(generated by mkfs.ubifs) should contains those reserved
unused LEBs and fill them with data 0xFF.

In our situation:
      After Nand flash is burned, product test begin. During those
test, all volumes are READONLY. Then final check goes to Volume
content CRC check. I need a
volume read tool to read the whole volume content and generate CRC.
Then have a comparition with the original volume image CRC.  This tool
is quite similar to ubidumpvol.
      If the ubifs.img(generated by mkfs.ubifs) contains ONLY mapped
LEBs, UBIFS volume and VFAT volume can share the same volume read
code.

      en..
      VFAT give me a hint, the file system reserved space are all
0x00. Like you allocate a space: reserved=malloc( 3LEBsize );  Though
you do not use it now, but you can init it memset(reserved, 0x00,
3LEBsize);  And if like that, the file system reserved space will
become mapped.
      Would you mind do this?

-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Artem Bityutskiy]

On Sat, 2008-05-10 at 12:20 +0800, Nancy wrote:
>        ubifs.img (generated by mkfs.ubifs) do contained unmapped LEBs.

This statement does not make sense. Mapped/unmapped is UBI notion, not
UBIFS.

>        #ubiupdatevol /dev/ubi0_0 ubifs.img   also write the unmapped
> LEBs to Nand flash.
It does not write them, but it creates them if the image size is less
then amount of space on the volume. What else do you expect?

>        Oh, There should have the same problem like I use nandwrite to
> write UBI image to Nand. But the practice tells everything is OK.

No, ubiupdatevol handles 0xFFs just fine.

> Example 2 shows
>        ubiupdatevol: error!: specify UBI device name and image file
> name as first 2 par
> ameters (use -h for help)
>        but
>        #ubiupdatevol /dev/ubi0_0 ubifs.img -t
>        instead, even the function do not need an input image file

Fixed, thanks for report.

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

Re: ubifs image file confusion!

[Artem Bityutskiy]

On Sat, 2008-05-10 at 15:31 +0800, Nancy wrote:
> I think UBIFS will reserved some logic block number for interal use.
> To keep a simple logic to build tool like ubiupdatevol
> ubifs.img(generated by mkfs.ubifs) should contains those reserved
> unused LEBs and fill them with data 0xFF.
> In our situation:
>       After Nand flash is burned, product test begin. During those
> test, all volumes are READONLY. Then final check goes to Volume
> content CRC check. I need a
> volume read tool to read the whole volume content and generate CRC.
> Then have a comparition with the original volume image CRC.  This tool
> is quite similar to ubidumpvol.

dd if=/dev/mtd5 of=file
or
dd if=/dev/ubi0_0 of=file

>       VFAT give me a hint, the file system reserved space are all
> 0x00. Like you allocate a space: reserved=malloc( 3LEBsize );  Though
> you do not use it now, but you can init it memset(reserved, 0x00,
> 3LEBsize);  And if like that, the file system reserved space will
> become mapped.
>       Would you mind do this?

Sorry, I still do not understand what is this all about. I do not
understand the problem.

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

Re: ubifs image file confusion!

[Nancy]

On Tue, May 13, 2008 at 5:44 PM, Artem Bityutskiy
<dedekind@infradead.org> wrote:
> On Sat, 2008-05-10 at 12:20 +0800, Nancy wrote:
> >        ubifs.img (generated by mkfs.ubifs) do contained unmapped LEBs.
>
> This statement does not make sense. Mapped/unmapped is UBI notion, not
> UBIFS.
   Cause I was writing ubi-util, sure I show this issue at UBI standpoint.
   OK, what mkfs.ubifs for? generate image file used by ubiupdatevol.
It should contain the necessary data. What is necessary data? at least
the data should be writen down on the Nand flash. On the standpoint of
UBI, those data should be mapped.  It does not make sense to contain
data(LEBs which contents are all 0xFF). ubiupdatevol have to play a
trick to avoid writing those 0xFF to Nand.
   As I fool understand which I have plase after that mail:

On Sat, 2008-05-10 at 15:31 +0800, Nancy wrote:
> I think UBIFS will reserved some logic block number for interal use.
> To keep a simple logic to build tool like ubiupdatevol
> ubifs.img(generated by mkfs.ubifs) should contains those reserved
> unused LEBs and fill them with data 0xFF.


> >        #ubiupdatevol /dev/ubi0_0 ubifs.img   also write the unmapped
> > LEBs to Nand flash.
> It does not write them, but it creates them if the image size is less
> then amount of space on the volume. What else do you expect?
   I do not mean that part of 0xFF.  I mean the unmapped part in the image file.


> > Example 2 shows
> >        ubiupdatevol: error!: specify UBI device name and image file
> > name as first 2 par
> > ameters (use -h for help)
> >        but
> >        #ubiupdatevol /dev/ubi0_0 ubifs.img -t
> >        instead, even the function do not need an input image file
>
> Fixed, thanks for report.

Thanks!

pls:
      1. ubinize tool do not check whether vol_id or vol_name's
uniqueness which may cause unexpected error.

      2. ubinize tool's volume size check do not aligned to LEB size.
I can't use an image file which taken up of its all volume space.
eg. LEB size =258048  , .cfg defined vol size = 100MiB ,
vfat.img(407LEBs)     fail
it say something like the image file size exceed the volume size. I'm
home now, can't plase the original error message here. sorry.



-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Nancy]

> dd if=/dev/mtd5 of=file
> or
> dd if=/dev/ubi0_0 of=file
dd have to specify the count, blk...... I mean read size, It is
difficult to get the size.
And the output file is large. We need a small output file (only
contain neccessary data).
Cause those files will be offered online. suppose, the /dev/mtd5 is
1G, or /dev/ubi0_0 is 500M
but the neccessary data only 10 or 100MiB. That waist too many space
and our bandwidth which is unacceptable.

> >       VFAT give me a hint, the file system reserved space are all
> > 0x00. Like you allocate a space: reserved=malloc( 3LEBsize );  Though
> > you do not use it now, but you can init it memset(reserved, 0x00,
> > 3LEBsize);  And if like that, the file system reserved space will
> > become mapped.
> >       Would you mind do this?
>
> Sorry, I still do not understand what is this all about. I do not
> understand the problem.
I mean will you please make the ubifs.img(generated by mkfs.ubifs)
contains all mapped LEBs? fill all ubifs.img's unmapped LEBs with
0x00. Is that possible?

-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Artem Bityutskiy]

On Tue, 2008-05-13 at 20:41 +0800, Nancy wrote:
>    Cause I was writing ubi-util, sure I show this issue at UBI standpoint.
If you want me to understand you and properly answer, you should try to
formulate things better. I understand language difficulties and this is
all right. I just ask you to try better, may be re-reading what you have
composed and trying imagine me reading your mail and imagine which part
could be not very clear for me.

>    OK, what mkfs.ubifs for? generate image file used by ubiupdatevol.
OK.

> It should contain the necessary data. What is necessary data? at least
> the data should be writen down on the Nand flash. On the standpoint of
> UBI, those data should be mapped.  It does not make sense to contain
> data(LEBs which contents are all 0xFF).
OK.

>  ubiupdatevol have to play a
> trick to avoid writing those 0xFF to Nand.
OK.

>    As I fool understand which I have plase after that mail:
Cannot parse this sentence, sorry.

> > >        #ubiupdatevol /dev/ubi0_0 ubifs.img   also write the unmapped
> > > LEBs to Nand flash.
> > It does not write them, but it creates them if the image size is less
> > then amount of space on the volume. What else do you expect?
>    I do not mean that part of 0xFF.  I mean the unmapped part in the image file.
Cannot understand what we are talking about here. What
'ubiupdatevol /dev/ubi0_0 ubifs.img' doing is:
1. Wipes out whole volume ubi0_0 which technically means unmapping all
LEBs.
2. Puts date from ubifs.img to the volume, starting from LEB 0.
3. If the ubifs.img file is less than the ubi0_0 volume, some amount of
LEBs at the end will be unmapped.


> pls:
>       1. ubinize tool do not check whether vol_id or vol_name's
> uniqueness which may cause unexpected error.

OK, will be fixed but a bit later.

>       2. ubinize tool's volume size check do not aligned to LEB size.
Cannot parse this.

> I can't use an image file which taken up of its all volume space.
> eg. LEB size =258048  , .cfg defined vol size = 100MiB ,
> vfat.img(407LEBs)     fail
> it say something like the image file size exceed the volume size. I'm
> home now, can't plase the original error message here. sorry.
Sorry, do not understand this.

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

Re: ubifs image file confusion!

[Artem Bityutskiy]

On Thu, 2008-05-08 at 17:56 +0800, Nancy wrote:
> #ubiupdate /dev/ubi0_0 ubifs.dp   (generated by ubidumpvol)
> 
> # mount -t ubifs ubi0:ubifs /mnt/1
> UBIFS: mounted UBI device 0, volume 0
> UBIFS: minimal I/O unit size:   2048 bytes
> UBIFS: logical eraseblock size: 258048 bytes (252 KiB)
> UBIFS: file system size:        102445056 bytes (100044 KiB, 97 MiB, 397 LEBs)
> UBIFS: journal size:            9420800 bytes (9200 KiB, 8 MiB, 37 LEBs)
> UBIFS: data journal heads:      1
> UBIFS: default compressor:      LZO
> UBIFS error (pid 598): ubifs_check_node: bad magic 0xffffffff, expected 0x610181
> UBIFS error (pid 598): ubifs_check_node: bad node at LEB 143:189920

This looks like you have not flashed UBIFS image properly or it was not
generated properly. UBIFS index refers a node, but the node is not there
and there are 0xFFs instead.

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

Re: ubifs image file confusion!

[Artem Bityutskiy]

On Tue, 2008-05-13 at 20:52 +0800, Nancy wrote:
> > dd if=/dev/mtd5 of=file
> > or
> > dd if=/dev/ubi0_0 of=file
> dd have to specify the count, blk...... I mean read size, It is
> difficult to get the size.
> And the output file is large. We need a small output file (only
> contain neccessary data).
> Cause those files will be offered online. suppose, the /dev/mtd5 is
> 1G, or /dev/ubi0_0 is 500M
> but the neccessary data only 10 or 100MiB. That waist too many space
> and our bandwidth which is unacceptable.

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.

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.

> I mean will you please make the ubifs.img(generated by mkfs.ubifs)
> contains all mapped LEBs?
Well... An UBIFS image file generated by mkfs.ubifs does contain some
LEBs which have only 0xFFs in it. And when you write this image file
using ubiupdate vol - these LEBs will be detected and UBI will leave
them unmapped.

>  fill all ubifs.img's unmapped LEBs with
> 0x00. Is that possible?

No, it is not.

I think I got it what is the problem you have hit. You drop unmapped
LEBs when you dump the volume, then you flash this dumped data back and
UBIFS cannot work anymore. Right?

Of course. UBIFS has the index which refers LEB numbers. And when you
drop unmapped LEBs the numbers change!

For example, you have mapped LEB3, unmapped LEB4, mapped LEB5. The UBIFS
index refers LEB3 and LEB5. You dump the volume and drop LEB4. Then you
flash the dumped image and LEB5 becomes LEB4! So the index now refers
incorrect LEB.

Basically speaking, you cannot do stuff like this. At least it is not
easy.

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.

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

Re: ubifs image file confusion!

[Nancy]

On 5/14/08, Artem Bityutskiy <dedekind@infradead.org> wrote:
> If you want me to understand you and properly answer, you should try to
> formulate things better. I understand language difficulties and this is
> all right. I just ask you to try better, may be re-reading what you have
> composed and trying imagine me reading your mail and imagine which part
> could be not very clear for me.
     OK, I admit I was in a hurry and have tried to use my bad English
to explain the issue, but failed. Then I think about to plase the
"ubidumpvol"  source code and tell you a way to reproduce the problem
I met. Thank God we still have a common language C. 90% of
"ubidumpvol" code are direct copy-plase from your tool "ubiupdatevol".
It should be no problem for you to quickly grasp its idea. But you
still push me hard to explain everything in English which makes me
disappointed and a little angry.

> >    As I fool understand which I have plase after that mail:
> Cannot parse this sentence, sorry.
        I mean I do not know the UBIFS implent detail. I just guess,
maybe it designed that way.  If you still can't parse, or still have
questions about that, please just ignore the whole. I already run out
of my brain to think about a suitable way to express.

> > pls:
> >       1. ubinize tool do not check whether vol_id or vol_name's
> > uniqueness which may cause unexpected error.
>
> OK, will be fixed but a bit later.
   Thanks!

> >       2. ubinize tool's volume size check do not aligned to LEB size.
> Cannot parse this.
>
> > I can't use an image file which taken up of its all volume space.
> > eg. LEB size =258048  , .cfg defined vol size = 100MiB ,
> > vfat.img(407LEBs)     fail
> > it say something like the image file size exceed the volume size. I'm
> > home now, can't plase the original error message here. sorry.
> Sorry, do not understand this.

$ cat ubinize.cfg
[ubifs]
mode=ubi
image=vfat.dump
vol_id=0
vol_size=100MiB
vol_type=dynamic
vol_name=vfat
vol_alignment=1

$ ./ubinize -o ubi.img ubinize.cfg -p 262144 -m 2048
ubinize: error!: error in section "vfat": size of the image file
"vfat.dump" is 105025536, which is larger then the volume size
104857600

LEB size = 258048,  volume 0 should contains 407 available lebs.
The volume size should be 407*258048 = 105025535  not 104857600.
The error message should not be triggered.

pls:
    You seems miss one issue
    # ubiupdatevol /dev/ubi0_0 rootfs.img (generated by mkfs.ubifs)
    # mount -t ubifs ubi0:rootfs /mnt/1
    # rm /mnt/1/* -rf
    # df
    The Use% of ubi0:rootfs is not 0%, but 2% which is unusual!


-- 
Best wishes,
Nancy

Re: ubifs image file confusion!

[Nancy]

On 5/14/08, Artem Bityutskiy <dedekind@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

Re: ubifs image file confusion!

[Artem Bityutskiy]

Hi,

On Wed, 2008-05-14 at 16:20 +0300, Artem Bityutskiy wrote:
> > pls:
> >       1. ubinize tool do not check whether vol_id or vol_name's
> > uniqueness which may cause unexpected error.
> 
> OK, will be fixed but a bit later.

Done.

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