santamasashiさんへ
このトピックの皆さんへ

私の推論から言うと、santamasashiさんは、ホームディレクトリ配下が全部eCryptfsで暗号化されている環境で、ホームディレクトリ配下に大きめのファイルをddで生成しようとしているから、遅いのではないか？と思います。

まず、~/.Privateは名前からして eCryptfs っぽいですね。
そして、#15のdfの出力を見ると、ホームディレクトリ全体(/home/yamada)をeCryptfsで暗号化対象にしてるように見えます。

#15 santamasashi による投稿:

~$ df
ファイルシステム           1K-ブロック    使用   使用可 使用% マウント位置
/dev/sda1            302105360   3297216 283462056   2% /
tmpfs                   964364         0    964364   0% /lib/init/rw
varrun                  964364       100    964264   1% /var/run
varlock                 964364         0    964364   0% /var/lock
udev                    964364       148    964216   1% /dev
tmpfs                   964364        84    964280   1% /dev/shm
lrm                     964364      2192    962172   1% /lib/modules/2.6.28-15-generic/volatile
/home/yamada/.Private
                     302105360   3297216 283462056   2% /home/yamada

試しに、私の環境で仮想PCを使い、
$ sudo apt-get install ecryptfs-utils
$ ecryptfs-setup-private
$ ecryptfs-mount-private
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             19734388   2519744  16212192  14% /
tmpfs                   254752         0    254752   0% /lib/init/rw
varrun                  254752        92    254660   1% /var/run
varlock                 254752         0    254752   0% /var/lock
udev                    254752       140    254612   1% /dev
tmpfs                   254752         0    254752   0% /dev/shm
lrm                     254752      2392    252360   1% /lib/modules/2.6.28-11-generic/volatile
/home/user/.Private   19734388   2519744  16212192  14% /home/user/Private
$ cd Private
$ dd if=/dev/zero of=uml-root-hardy bs=4096 seek=1M count=1
で、全く反応が返らなくなりました。(sudo kill -s KILLさえできず、仮想PCごとシャットダウンしました）

seek数を約1/10に減らして、
$ dd if=/dev/zero of=uml-root-hardy bs=4096 seek=100000 count=1
でさえ23秒かかりました。

逆に、/tmpでやったら、
$ cd /tmp
$ dd if=/dev/zero of=uml-root-hardy bs=4096 seek=100000 count=1
は1秒くらいです。(私の環境では/tmpはeCryptfsで暗号化対象じゃないので)

※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。

kiyoshi による投稿:

STGSAGWANさん、「.Private」が名前からしてeCryptfsらしいということをご教示くださり、有難うございました。

santamasashiさんへ

インストールする時に、ホームディレクトリの暗号化とかを選ばれましたか？
もしくはeCryptfsとかを自分で導入されましたか？

eCryptfsは止めておいた方が良さそうですね。

でかいデータをeCryptfs経由で書き込もうとしたら lockdep がデッドロックを検出し、そもそも動かなかった。

ホームディレクトリの暗号化を選びました。それが問題ですか？
eCryptfsは導入していません。

※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。

もう一度再インストールして行ってみます。
本当に何度もありがとうございます。

また何かありましたらよろしくお願いします。

kiyoshi による投稿:

参考：
KaiGaiの俺メモ「これはひどい！」

でかいデータをeCryptfs経由で書き込もうとしたら lockdep がデッドロックを検出し、そもそも動かなかった。

この当時のlockdep問題はすでに直っているので、あまり適切な例ではないかと思います（cryptfs+lockdep周りが鬼門なのは間違いない＆今も別のところを直しているものの、この問題は直っています）。

大量のスパースを含んだファイルを作ろうとするとフリーズしたかのように見える（裏ではひたすらスパースを暗号化しているが、処理が追いつかないのでI/O waitが爆発的に増大する）という問題が起こるのは事実なので、結論である「今回はeCryptfsは避けるべき」は妥当なのですが、根拠としては正しくないかと思います。

微妙にoff-topicではあるのですが、ecryptfsを理由なく避けるのもうれしくないので書いておきます……。