確認ですが、1から5までを一連の操作として行ったのでしょうか？（途中で他のコマンドなどを実行したり、各操作の間に時間が開いているということはないのですね？）
もし、そうならば、２つほど気がかりな点があります。

まず、SD カードのサイズが大きくない（kernel I/O buffer に使えるメモリーの量よりも小さい）場合には3で書きだしたデーターは kernel 内に buffering された値でカードから読み出されたデータではない可能性が高いです。本当に SD カード上のデーターと比較したいのであればデバイスを再認識させるなど、メモリー上の情報を破棄させる必要があります。reboot すれば確実ですが、もし、USB接続のSDカードアダプターを使っているのなら 14.04 では

udisksctl power-off -d /dev/sdb
USBケーブルを抜く
しばらく待って(機種にも依りますが10秒もあければ大抵大丈夫です）再びUSBケーブルを入れる

とすれば再認識させられます。

次に、仮にSDカードに情報が正しく書きだされていてメモリー上のデーターとSDカード上のデーターが一致している場合でも、手順5の前にパーティションテーブルの再読み込みが必要です。デバイスを再認識させればこれは再認識の過程で自動的に行われますが、コマンドラインからマニュアルで再読込させるなら

blockdev --rereadpt /dev/sdb

です。

（というか、パーティションテーブルを再読み込みしていないのになぜ30%もうまく行くのかがわかりません。たまたますべてのパーティションテーブルが同じなのでしょうか？）

本題の原因とは関係ありませんが、カードに書き出すべきイメージファイルが既にディスク上にあるのですから私なら md5sum は使わずに 手順 3,4 の代わりに
cmp 元となるイメージファイル  /dev/sdb
とします。不一致があった場合にどこで有ったかわかります。

taka.zoo.n　様

お世話になります。
ご回答ありがとうございます。
大変勉強になりました。

>1から5までを一連の操作として行ったのでしょうか？
⇒おっしゃる通りです。
　シェルスクリプトを書いて実行しました。

>SD カードのサイズが大きくない場合には3で書きだしたデーターは kernel 内に buffering された値でカードから読み出されたデータではない可能性が高いです。
⇒結論的には、大丈夫そうです。（4GBのイメージを読み書きしており、メモリーよりもサイズが大きい為。）
　とは言え、この視点のチェックを見落としていたのも事実でした。（conv=fsyncの指定で安心していました）

cat /proc/meminfo
Buffersは数十M程度


>仮にSDカードに情報が正しく書きだされていてメモリー上のデーターとSDカード上のデーターが一致している場合でも、手順5の前にパーティションテーブルの再読み込みが必要です。
⇒このご指摘内容が、ほぼ100%の原因だと思います。(他の原因も疑う理由は最後に記述しました。)
手元のマシン（質問時のマシンとは異なる⇒※1）で掲題の現象が起きるのを確認したうえで、
パーテーションテーブルの再読み込みをした結果、無事マウントできました。

※1 質問時のマシンとリーダーは来週月曜日まで、貸し出しており、手元のマシンで評価しました。

>というか、パーティションテーブルを再読み込みしていないのになぜ30%もうまく行くのかがわかりません。
推測ですが、
検証時、空のSDカード（パーテーションテーブルが異なる）に書くパターンと、
一度同じイメージファイルを書き終えたSDカードを挿し直し、書き込みするパターンの2パターンありました。

後者の場合、挿し直した時に読み込まれたパーテーションテーブルをOSが覚えていた為に書き込み後のマウントがうまく行ったのだと思います。・・

>本題の原因とは関係ありませんが、カードに書き出すべきイメージファイルが既にディスク上にあるのですから私なら md5sum は使わずに 手順 3,4 の代わりに
>cmp 元となるイメージファイル  /dev/sdb
>とします。不一致があった場合にどこで有ったかわかります。

⇒ありがとうございます。
　頂いたアドバイスの方が、便利で合理的ですね。

【他の原因も疑う理由】
イメージ書き込みを終えたSDカードを物理的に挿し直しても、マウントができない時がありました。
（逆にマウントできる時もありました。）

書きミスが起きてしまう時もあるのだと思います。
これについて、もしアドバイスをお持ちでしたら、記載いただけますと幸甚に存じます。

taka.zoo.n　様

アドバイスありがとうございます。

本日、まさに書き込みミスを確認しました。
教えていただいたsyslogログからもエラーを確認しました。
（USBカードリーダーでも確認できました。）

2回連続、しかも異なるSDカードで発生しました。
原因は不明ですが、低い確率とは思えません。

解析はこれからですが、
取り急ぎ、お礼と最初の報告まで。

すみません。訂正です。

conv=fsync（と conv=fdatasync）は dd の処理を終了する直前に一度だけ同期処理を行うので block size の指定はメモリーカードへの入出力に影響を与えません。
# oflag=sync の場合と混同してしまいました。
oflag が何も指定されていないので kernel からメモリーカードへの書き出しは dd の bs 指定にかかわらず kernel で buffering されます。従って #8 は今回の問題とは全く関係がありませんのでお詫びして取り消します。申し訳ございません。

bushin による投稿:

#8で、「最悪の場合、カードの寿命も縮めます」とございますが、
その理由をお聞かせ願えませんでしょうか？（カードの書き込み回数？？）

はい、書き込み回数です。

oflag=sync や oflag=direct の場合は dd のブロックサイズごとに device driver に write（oflag=sync ならそれに加えて flush)が device driver に送られます。 bs を適切に設定しないとユーザーは一度しか書いていないと思ってもメモリーセルへの書き込み回数が膨れ上がってしまう可能性があります。この比率 (write amplification; WA)は例えば dd の bs が default(512B) でSD カードのページサイズが 2KB なら最悪 4倍、16KB なら最悪 32倍です。「最悪」と書いたのは実際には SD カード内部でもバッファリングされるからですが、この部分が具体的にどのような処理になっているかは不明です。

conv=fsync の場合は kernel の buffering のため dd に与える bs の値は WA には影響しません。

お世話になります。

#3で教えていただいたkernel I/O bufferですが、コピー、読み出し時に　bufferを使用しないようにサイズの変更をする事は可能でしょうか？

bushin による投稿:

#3で教えていただいたkernel I/O bufferですが、コピー、読み出し時に　bufferを使用しないようにサイズの変更をする事は可能でしょうか？

ふと疑問に思ったのですが、dd で対処する必要があるのでしょうか？もし「dd  で SD カードイメージを書き込むときに kernel に cache されたデーターを破棄させて、内容を比較するときにカードアダプタから read させる」のでよければカードイメージを書き込んだ後に

blockdev --flushbufs デバイス名

を実行すればそのデバイスに対応付けられた kernel cache をすべて破棄できるはずです。「はずです」と書いたのはデバイスドラーバーが独自の処理を行い、kernel cache が全く処理されない場合があるからです。（ですが、/dev/sd* ではそのようなことはなく、常に cache が破棄されるというのが私の理解です。）

なお、ご質問の主旨からは外れるかもしれませんが、この方法や dd に nocache を渡すなどで kernel の cache を破棄しても、USB-SDカードアダプターに cache されたデーターは影響を受けません。従って SD カードからの読み出しを確実に担保することはできないと思います。

taka.zoo.n　様

お世話になります。

#15のご回答、ありがとうございます。
#16は#14に対する返答でした。（更新を見逃してしまってました。）

>blockdev --flushbufs デバイス名
>を実行すればそのデバイスに対応付けられた kernel cache をすべて破棄できるはずです。
ありがとうございます。
自分でも確認をしたく、カーネルソースをダウンロードして読んでみました。
それらしい箇所（BLKFLSBUF時、最後にcleancache_invalidate_inodeしている）を発見しました。

>なお、ご質問の主旨からは外れるかもしれませんが、この方法や dd に nocache を渡すなどで kernel の cache を破棄しても、USB-SDカードアダプターに cache されたデーターは影響を受けません。従って SD カードからの読み出しを確実に担保することはできないと思います。

⇒だから、#3のご回答でUSBケーブルを抜き、10秒待ち、接続するように、教えてくださったのですね
　恥ずかしながら、理解できていなかったです。。

　このご忠告の部分、今後のやり方を検討するのに、かなり重要なアドバイスになりました
　感謝しております。

taka.zoo.n　様

お世話になります。
ご回答ありがとうございます。

>ブロックサイズを設定していないか、値が小さすぎるということはありませんか？
⇒おっしゃる通りです。
　bsは何を意味するのかを、はっきり分かっておりませんでした。

　最後の方に質問を記載しました。ご回答頂けますと、幸いです。

bsの設定方法について調べたことを以下に記載しました。
**************************************************************************************************************************
〔私なりの結論〕
　bsは、SDカードに書き込む際の1ブロック当たりのサイズに影響する値。
　ただし、実際には、SDの規格（ブロックサイズレジスタ）や、実際に使用するハードウェアに制限され、適切な値に設定しないと、十分なパフォーマンスが得られないことがある。

〔結論への過程〕
　SDアソシエーションが発行しているSDホストコントローラーの規格書を読みました。
　ブロックサイズレジスタというレジスタがあり、1データ当たりのブロックサイズを決める物のようで、指定できるサイズは決まっている事を知りました
　ddのbsでどんな値を設定しようと、結局書き込み時には、このレジスタで設定するサイズに限られるのではと、考えました。
　
　taka.zoo.n　様が回答くださった64kも此処から選択されているのではと推測しました。

　（1）まず、bsをレジスタで設定できるサイズに設定し、ddで約400MBのデータの書き込み処理を行ってみました。（oflag =direct ）
　結果、64kが最も早く書き込めました。

　　32k・・・4.3MB/s
　　64k・・・10.3MB/s・・・・・・最も早い
　　128k・・・6.3MB/s
　　256k・・・7.5MB/s
　　512k・・・7.6MB/s

　（2）続いて、64kに近い63k,65kで書いてみました。結果、64kに比べ、スピードが大きく落ちました。（oflag =direct ）
　（ドライバ等のCPU処理が入るため？）
　　63k・・・6.1MB/s・・・・・・64k時と比べ、速度が40%減。
　　65k・・・6.5MB/s

　（3）なぜ、64kが最も早かったのかを考えました。
　#9で教えていただいた、max_hw_sectors_kbを確認すると、120kbyteでした。
　レジスタに設定できるサイズの内、120kbyte以下、且つ最大の値は64kであったために64kなのではと考えました。
　（Linuxが　max_hw_sectors_kbをどうやって設定するかは調べていません。。）

　　120kbyte・・・7.6MB/s

　（4）最後に、oflag =direct指定無、bs指定無で書き込みをしてみました。（conv=fsync）
　結果、そこそこのパフォーマンスを得られたものの、oflag =direct指定、bs=64kには届きませんでした。
　（却って、キャッシュする分時間がかかる？）
　conv=fsync・・・・8.6MB/s


※計測値
ddの結果を記載。
それぞれ2,3回繰り返し、ばらつきが小さく、傾向は変わらないことを確認したうえでの結果。

**************************************************************************************************************************

【ご質問】
taka.zoo.n様がおっしゃる通り、bs=64kにしたことで、oflag にdirect を指定しなかった場合と同等以上の書込速度を得られました。（最も効果的な値のようでした。）
64kbyteと、ご指定になった理由をお聞かせ願えませんでしょうか？
また、厚かましく恐縮ですが、上記に記載した実験、私の結論に対しましてもコメントを頂けますと、幸いです。（長ったらしい文で、申し訳ありません。）

taka.zoo.n様

お世話になります。
ご回答いただきまして、ありがとうございます。
本当に参考にさせて頂いてます。

>SD カードが書き込み完了を報告してくるまでの時間が必要ならdd には oflag=direct conv=fsync の２つを渡して測定すべきです。
>（fdatasync は device driver に flush request を出し、これは仕様上は出力の完了を待つことになってるため。）

conv=fsync指定でSDからの書き込み完了まで待つ事を知りませんでした。
データを物理的に何処まで書いたのか把握できることは重要なポイントでして、今回だけではなく、今後にも役に立ちそうです。

>device driver への write request がSDカードに対するどの命令にどのように変換されるかはカードアダプター依存（かつユーザーにとってはブラックボックス）だと思います。
この点を念頭に入れながら、もう少し、勉強を進めたいと思いました。

先ずは、お礼まで。

taka.zoo.n様

お世話になります。

>特に SDカードアダプターを使っている場合にはデバイスドライバーが検出できるのはカードアダプターからの完了のみです。
追っての情報ありがとうございます。
もとは、私がmmcblkとsd*の違いをよく理解できていないために起きた勘違いでした。

カードリーダーを使用したとき、SDカードをUSBマスストレージデバイスとして認識していて、
SDを直接制御していないためにブラックボックスになってしまうという事ですね。

壊れたSDカードリーダーを持っていたので、分解してみると、
Alcor micro社のAU6371というチップが載っていました。このようなチップと通信していたのですね。
当然、USB MASS Storage対応でした。