# Slow writes on Up Squared

**URL:** <https://hub.mender.io/t/slow-writes-on-up-squared/924>\
**Category:** General Discussions\
**Created:** [June 23, 2019, 11:57am UTC](https://hub.mender.io/t/slow-writes-on-up-squared/924 "2019-06-23T11:57:59Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dbensoussan](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dbensoussan/32/263_2.png) [@dbensoussan](https://hub.mender.io/u/dbensoussan)\
**Post date:** [June 23, 2019, 11:57am UTC](https://hub.mender.io/t/slow-writes-on-up-squared/924/1 "2019-06-23T11:57:59Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [June 24, 2019, 7:37am UTC](https://hub.mender.io/t/slow-writes-on-up-squared/924/2 "2019-06-24T07:37:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dbensoussan](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dbensoussan/32/263_2.png) [@dbensoussan](https://hub.mender.io/u/dbensoussan)\
**Post date:** [June 24, 2019, 7:54am UTC](https://hub.mender.io/t/slow-writes-on-up-squared/924/3 "2019-06-24T07:54:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dbensoussan](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dbensoussan/32/263_2.png) [@dbensoussan](https://hub.mender.io/u/dbensoussan)\
**Post date:** [June 24, 2019, 2:21pm UTC](https://hub.mender.io/t/slow-writes-on-up-squared/924/4 "2019-06-24T14:21:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [June 24, 2019, 2:25pm UTC](https://hub.mender.io/t/slow-writes-on-up-squared/924/5 "2019-06-24T14:25:00Z")

</div>

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