mkfs.ubifs, ubinize, ubiupdatevol request!

mkfs.ubifs, ubinize, ubiupdatevol request!

[Nancy]

Hi all,
       First of all, please accept my deeply apologize to Artem
Bityutskiy. I'm sorry for my bad question expression and bad attitude.
No matter what, I should be thankful for all your replies to me.
That's all my bad, so sorry!
       I still need your guilde and help, please!

       # mkfs.vfat /dev/ubiblock0
       the cp file speed is 800kb/s -1.3Mb/s. on target board. but
when connect with PC.
       # modprobe g_file_storage file=/dev/ubiblock0
      cp files speed too slow about 200kb/s, But after use windows
fast FAT32 format program, the cp speed up to 800kb/s -1.3Mb/s.

       I don't know what's the detail differences between mkfs.vfat
and windows format program.  For me, the speed problem is really hard
to find. Is there anyone who can give me a hint?

       What I do know is mkfs.vfat will write LEB from 0-N
continuesly, but windows format program will write LEB from 0-N plus
the last LEB.
       If I use windows format program to avoid the speed problem,
then the new problem comes out.
       when I dump VFAT volume to a file, there have ummapped LEBs in
between Cause the windows format program will write the last LEB. But
I can't dump the ummaped LEBs to files due to the dump file size
limitation. So I have to teach ubiupdatevol and ubinize to .....   Oh
please, that's really hard things for me.

To mkfs.ubifs:
       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 | ...........................
-------------------------------------------------------------------

To ubinize and ubiupdatvol, the implement logic maybe easier.

But, I have not enought knowlege to change mkfs.ubifs work that way.
So, will you please help?

Thanks a lot!
Apologize again!

-- 
Best wishes,
Nancy

Re: mkfs.ubifs, ubinize, ubiupdatevol request!

[Nancy]

On 5/29/08, Meihui Fan <mhfan@hhcn.com> wrote:
>
> Hi Nancy,
>
> I don't know the difference between mkfs.vfat and windows fast fat32 format
> program, but  in my experience, I think there are two arguments for
> mkfs.vfat which would impact the block access performance: -s and/or -S,
> please try to specify a big value for these two arguments.
>
> Hopeful this would help.

I have tried several pair, but none was same as winodws fast fat32
format program.
Would you please give me an example?

By the way, are you using my ubiblk patch now? Have you meet the same
speed problem? How do you solve it?

Thank you for your reply :-)

-- 
Best wishes,
Nancy

Re: mkfs.ubifs, ubinize, ubiupdatevol request!

[Nancy]

On 5/29/08, Meihui Fan <mhfan@hhcn.com> wrote:
>
>Nancy wrote:
> > I have tried several pair, but none was same as winodws fast fat32
> > format program.
> > Would you please give me an example?
> >
> > By the way, are you using my ubiblk patch now? Have you meet the same
>
> No. I didn't have a chance to using your ubiblk patch. But I think it is
> useful, and it would very nice if your patch (if you do some further work as
> the UBI guys pointed out) or a similar one to be merged into UBI and
> mainline kernel. Then I and many other people would benefit from this in the
> future.
   Yes, you are quite right! But I guess most MTD developers have more
interesting in Alex Dubov future FAL patch.

> > speed problem? How do you solve it?
>
> I met a similar block access performance issue for the SD/MMC card in my
> target. I solved it by merge several continues single small block access
> into a bigger batch one.

I see, thanks!


-- 
Best wishes,
Nancy

Re: mkfs.ubifs, ubinize, ubiupdatevol request!

[Artem Bityutskiy]

Hi,

On Thu, 2008-05-29 at 15:02 +0800, Nancy wrote:
>        I don't know what's the detail differences between mkfs.vfat
> and windows format program.  For me, the speed problem is really hard
> to find. Is there anyone who can give me a hint?

I do not know much about vfat and cannot help here.

>        when I dump VFAT volume to a file, there have ummapped LEBs in
> between Cause the windows format program will write the last LEB. But
> I can't dump the ummaped LEBs to files due to the dump file size
> limitation. So I have to teach ubiupdatevol and ubinize to .....   Oh
> please, that's really hard things for me.

Actually what we could do is to create a simple program which would dump
whole _MTD_ device, and basically drop unmapped physical eraseblocks.
This is just easier to do. Something like this:

fd = open(/dev/mtdX);
for (each physical eraseblock) {
	read(fd, buf, peb_size);
	/* Check if PEB is not mapped by checking that there is not VID
           header */
	if (vid_header_is_not_present())
		/* This PEB is unmapped, it is safe to drop it and
		   switch to the next PEB */
		continue;
	/* Write data to the output file */
	write(output_file_descriptor, buf, peb_size);
	
}

Afterward, you will be able to just flash the resulting dump with
"ubiformat".

But of course, you will dump all volumes this way, not just one. Does
this work for you?

This should be easy to write this tool. I could do this but I am very
busy at the moment and basically have not time, may be later.

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

Re: mkfs.ubifs, ubinize, ubiupdatevol request!

[Nancy]

On 5/30/08, Artem Bityutskiy <dedekind@infradead.org> wrote:
> Actually what we could do is to create a simple program which would dump
> whole _MTD_ device, and basically drop unmapped physical eraseblocks.
> This is just easier to do. Something like this:
>
> fd = open(/dev/mtdX);
> for (each physical eraseblock) {
>        read(fd, buf, peb_size);
>        /* Check if PEB is not mapped by checking that there is not VID
>           header */
>        if (vid_header_is_not_present())
>                /* This PEB is unmapped, it is safe to drop it and
>                   switch to the next PEB */
>                continue;
>        /* Write data to the output file */
>        write(output_file_descriptor, buf, peb_size);
>
> }
>
> Afterward, you will be able to just flash the resulting dump with
> "ubiformat".
>
> But of course, you will dump all volumes this way, not just one. Does
> this work for you?
That's a greate idea to create UBI image for Nand burning, but I also
have to support the volume update functions. Cause products update is
used more ofen than Nand burning.

So I have no choices but write a tool to reformate ubifs.img(generated
by mkfs.ubifs), fix ubinize, ubiupdatevol.

> This should be easy to write this tool. I could do this but I am very
> busy at the moment and basically have not time, may be later.
It's OK. I'm so happy to get your reply. That mean you have already
forgive me.  Thank you!  * ^_^ *

-- 
Best wishes,
Nancy