Estou usando este pipeline para gravar um arquivo de imagem para dirigir $drive:
wget -o logfile -O - https://route/to/image.gz | \
gunzip -c | \
dd of="$drive" bs=4M conv=fdatasync 2>/dev/null
logfileé criado para monitorar o progresso.
Tenho um mau pressentimento sobre isso e não consigo me convencer de que é infalível. A imagem em si é sempre um múltiplo de 4 MB, então isso não é um problema, mas ddé potencialmente problemático (veja esta resposta da U&L , por exemplo).
Estou sendo paranoico ou existe uma maneira melhor de fazer isso?
EDITAR
Seguindo os comentários (obrigado), eu fiz um benchmarking head -ce dd bs=1para escrever uma imagem em uma unidade. TL;DR: ddé basicamente inútil nesta aplicação. A imagem no servidor remoto compacta em gzip para cerca de 46M, então ddé usada com bs=1, então isso talvez seja um pouco injusto com dd. A imagem é recuperada com wget, gunzipada na hora e então gravada na unidade com head -cou dd bs=1:
Opção 1:
# time wget -o logfile -O - https://path/to/foo.img.gz | \
gunzip -c | \
dd of=/dev/sda bs=1 conv=fdatasync 2>/dev/null
real 1m55.665s
user 0m32.323s
sys 2m20.841s
Opção 2:
# time wget -o logfile -O - https://path/to/foo.img.gz | \
gunzip -c | \
cat > /dev/sda 2>/dev/null
real 0m7.419s
user 0m0.646s
sys 0m0.507s
Ambas as opções foram testadas obtendo-se o md5sumand sha256sumdos primeiros 48159047 bytes da unidade, e ambas forneceram a pré-compressão correta md5sum, sha256sumconforme encontrado no servidor:
# time head -c 48159047 /dev/sda | md5sum
b3df12b61df3121ad112f825cc6fe8b7 -
real 0m0.222s
user 0m0.075s
sys 0m0.049s
# time dd status=none if=/dev/sda bs=1 count=48159047 | md5sum
b3df12b61df3121ad112f825cc6fe8b7 -
real 1m31.627s
user 0m49.218s
sys 1m45.406s
Os sha256sumresultados foram praticamente os mesmos: cerca de 0,25 s de tempo real para head -c, e 1 m32 s para dd.
