上の写真にはダウトがあります。持ってる人ならすぐに分かると思いますが、正しくは次の写真のようになるはずです。
iPod touchには加速度センサーが内蔵されていて、音楽を演奏しながら横向けにするとカバーフローの画面になるはずなのに・・・画面が変わりません(T^T)。
でも正常に戻す裏技がありました。なんと、叩けば直る(^_^)。なんだか昔のテレビみたいですね。
具体的な直し方はこちらをご覧ください。
→http://jp.youtube.com/watch?v=Oa1FqkW_A9s
WindowsからiSCSIで作ったドライブで hdbench を走らせるとずいぶん数値が悪いZFSですが、実際にはどれくらい違うのでしょうか? FreeBSD上で簡単なベンチマーク試験をしてみました。
測定に用いたのは下記のシェルスクリプト。
#!/bin/sh
echo "write: " ;time dd if=/dev/zero of=tmpfile1 bs=1M count=1000
echo "read: " ;time dd if=tmpfile1 of=/dev/null bs=1M count=1000
echo "copy: " ;time cp tmpfile1 tmpfile2
rm tmpfile1 tmpfile2
| ファイルシステム | WRITE | READ | COPY | ||
|---|---|---|---|---|---|
| (秒) | (MB/秒) | (秒) | (MB/秒) | (秒) | |
| ZFS | 15.8 | 66 | 14.5 | 73 | 30.2 |
| UFS | 15.2 | 68 | 0.9 | 1,127 | 15.5 |
ZFSではREADにえらい時間がかかっています。てゆーかこれは、UFSが速すぎなんですね。全部キャッシュにハマってるからでしょうか。1GBなんて量がキャッシュにすっぽりハマるとは恐ろしい時代になったものです。
ということで、一桁増やして10GBの読み書きも試してみました。
| ファイルシステム | WRITE | READ | COPY | ||
|---|---|---|---|---|---|
| (秒) | (MB/秒) | (秒) | (MB/秒) | (秒) | |
| ZFS | 164 | 63 | 160 | 65 | 324 |
| UFS | 159 | 65 | 152 | 68 | 448 |
メモリを8GB積んでることを考えればこれで十分な確証はないのですが、それなりに正統性のある数字がでてきました。
ZFSプールがディスク全体であること・UFSディスクはスライスをいくつかに区切った後ろのほうを使用していることを考えると このテストはUFSには若干不利な条件ではあるのですが、このサイズになるとZFSでもUFSでもそう大きく変わらないといったところでしょうか。1GBテストでは明らかにUFSのほうが分がありますから、 make world のように書き込み後すぐに読みだされるデータが多い場合は UFS の方が良い結果になるかもしれません。ただ、ZFSでは読み書きサイズによって制御を変えてる可能性もありますし、上の試験結果だけでは何とも言えません。
とはいえ、連続転送のパフォーマンスは思ったより悪くないようですので 再起動問題が現れなければサーバのファイルシステムとして常用して問題なさそうです。
上の写真にはダウトがあります。持ってる人ならすぐに分かると思いますが、正しくは次の写真のようになるはずです。
iPod touchには加速度センサーが内蔵されていて、音楽を演奏しながら横向けにするとカバーフローの画面になるはずなのに・・・画面が変わりません(T^T)。
でも正常に戻す裏技がありました。なんと、叩けば直る(^_^)。なんだか昔のテレビみたいですね。
具体的な直し方はこちらをご覧ください。
→http://jp.youtube.com/watch?v=Oa1FqkW_A9s