Slow writes on Up Squared

Hi @mirzak ,
I have recently been involved on the production of a product requiring to flash more than 50 up squared boards with a Yocto based os. The zcat step was taking around 25 minutes which was definitely too long.
I investigated some alternatives such as network boot to flash the initial image, but didn’t have the time to make tests with Yocto (It is quite easy with ubuntu though). Here is an alternative:

By piping directly, i went from 25 minutes to 4 minutes only:
< /path/to/image.gz pv | gunzip > /dev/mmcblk0

For those interested, why is it happening. dd has some more features, for example to write from/to a certain point, which can be handy when repairing a disk, but not really useful in this use case.
Some of the features that are also slowing the process are actually to write on … tapes. Which we hopefully don’t. More about it here: https://unix.stackexchange.com/questions/12532/dd-vs-cat-is-dd-still-relevant-these-days .

Maybe you can edit this page and other boards that are flashing the image in a similar way.

Hi @dbensoussan, thanks for sharing this information. It makes sense to skip dd if possible.

By piping directly, i went from 25 minutes to 4 minutes only:
< /path/to/image.gz pv | gunzip > /dev/mmcblk0

This time difference, is this with flushing buffers e.g using sync?

Also there is one obvious thing with the dd command in the examples which can improve speed significantly and that is setting a larger block size. The default is 512 bytes, and e.g using dd of=/dev/mmcblk bs=8M will probably be comparable to cat or piping and I would expect the write/read speed of the hardware being the bottleneck and not performance of dd or cat.

I will give this some more thought before changing all posts. Would be nice to write more detailed report comparing the different methods.

Yes, it includes the syncing. Doing comparisons makes sense. I’ll do that during the week.

Just a heads up on this, you were right, the bs=8M made the difference and gives same result as piping.

Thanks, I have updated this post with the bs=8M argument at least.