On Thu, Dec 15, 2011 at 10:28:38AM +0100, Robert Jarzmik wrote:
> Robert Jarzmik <robert.jarzmik@xxxxxxx> writes:
>
> > Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> writes:
> >> It would be great if you could give it some testing as obviously my test
> >> patterns didn't reveal the 'create folder' bug you described.
> > Tomorrow or wednesday, I'll make the few tests I always do (making a
> > directory, copying a file, deleting a file, etc ...) and report.
> This is what my tests give back:
>
> **** With FAT caching (barebox.git/next + rjk mioa701 support):
> barebox:/sdcard time bmp /sdcard/help.bmp
> time: 6895ms
> barebox:/sdcard time cp /sdcard/help.bmp /sdcard/toto.tmp
> time: 13278ms
> barebox:/sdcard ls -l help.bmp
> -rwxrwxrwx 230454 help.bmp
> barebox:/sdcard
There is something wrong. These times are far from being acceptable.
Here's what I get with copying a 2MiB file from SD Card:
barebox@Freescale i.MX51 PDK:/ time cp /fat/x /x
time: 273ms
>
> **** Without FAT caching (merged pu/block into barebox.git/next + rjk mioa701 support)
> barebox:/sdcard time bmp /sdcard/help.bmp
> time: 9219ms
> barebox:/sdcard time cp /sdcard/help.bmp /sdcard/titi.tmp
> BUG: failure at common/block.c:248/block_
Hm, I don't understand where this can come from.
data = block_get(blk, block);
if (!data)
BUG();
So this bug is triggered when block_get fails:
static void *block_get(struct block_device *blk, int block)
{
void *outdata;
int ret;
if (block >= blk->num_blocks)
return NULL;
outdata = block_get_cached(blk, block);
if (outdata)
return outdata;
ret = block_cache(blk, block);
if (ret)
return NULL;
outdata = block_get_cached(blk, block);
if (!outdata)
BUG();
return outdata;
}
So block_get fails when
a) You access some block outside the device (which should have been
caught earlier
b) block_cache fails. (This indeed can fail when the underlying hardware
fails to read the block, so the BUG should be replaced with a simple
error return)
>
> The "BUG" thing prevents me from going further. But it seems the cache in main
> tree speeds up things. I also think that creating directories without files
> serves no purpose I can think of, and is an acceptable tradeoff for the improved
> performance.
It's not only the creating-directory-without-files thing, The FAT can
become corrupted in current mainline, so we have to do something.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
