2012-05-13
潜在的なディスクエラー………恐ろしい子!
「Windows の次世代ファイル システム: ReFS」を読んだ。
私にとって、ReFSでいちばん欲しい機能は、潜在的なディスク エラーを防ぐディスク スクラブ処理だ。
気づかないうちにデータが回復不能になるかもしれないというのは不安だ。
ReFSではこれへの対策が入るという。
だから今すぐにでもReFSが欲しいのだが、いつ使えるようになるのか分からない。
「ディスクの 一部が経時的に破損していき、読み取りが頻繁に行われないためにそのことが検出されない事態」は、ときどき全ファイルを読み込んでみれば防げるのでは? と思い、cygwin で以下のようなコマンド*1を実行してみた。
/bin/find d:/ -type f -exec cat {} \; > /dev/null
一応これで全ファイルを読むことができるはず。読み取りエラーが発生すればわかるので、バックアップがあるファイルは回復できる。
この方法の問題点はシステム全体の性能が低下することだ。おそらくディスクキャッシュの中身がすべて役に立たないものにされてしまうからだろう。操作に対する応答が、使い物にならないほどに遅くなってしまった。
というわけで、キャッシュを汚さずにファイルの中身を読み込むコマンドを作ることにした。CreateFile のフラグに一つ追加するだけなので難しくはない。大した大きさじゃないので、なくさないようにここにメモっておくことにした。ファイルにコピペして、cl.exe でコンパイルすれば使える。第一引数がファイル名だ。
#include <windows.h> #include <stdio.h> #include <stdlib.h> #define READ_BYTES (100 * 1024 * 1024) int main(int argc, char* argv[]) { void* buf; DWORD totalBytesRead = 0; DWORD numberOfBytesRead; HANDLE hFile = CreateFile(argv[1], GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING | FILE_FLAG_SEQUENTIAL_SCAN, NULL); if (hFile == INVALID_HANDLE_VALUE) { fprintf(stderr, "CreateFile failed(%d): %s\n", GetLastError(), argv[1]); return 1; } buf = _aligned_malloc(READ_BYTES, 4 * 1024); if (buf == NULL) { fprintf(stderr, "_aligned malloc failed.\n"); return 2; } while(1) { if (ReadFile(hFile, buf, READ_BYTES, &numberOfBytesRead, NULL)) { if (numberOfBytesRead == 0) { // printf("total %u bytes\n", totalBytesRead); break; // 読み終わりました。 } totalBytesRead += numberOfBytesRead; } else { fprintf(stderr, "ReadFile error (%d): %s\n", GetLastError(), argv[1]); break; } } _aligned_free(buf); CloseHandle(hFile); return 0; }
これをhoge.exe などの名前でPATHの通ったところにおいて、
/bin/find d:/ -type f -exec hoge {} \;
とすればきっと目的が達成できるにちがいない。
今のところ、システム全体が遅くなるようなこともなく、快適に動いている。
ReFSが使えるようになるまで、ときどきこれで全ファイルを読み込んでみようと思っている。
ディスクのエラーを発見できるかどうかは、テストデータを用意できないので、出てみてからのお楽しみなのだけど。
2012-03-29
JavaScriptの文字って馬鹿なの?死ぬの?
何か大げさなタイトルだが、ホッテントリメーカーが出したのをそのまま貼ることにしているので。
「JavaScript’s internal character encoding: UCS-2 or UTF-16?」を読んだ。
JavaScriptでいう文字というのは、16ビットの数値のことなのだそうだ。
つまり、サロゲートペアは2文字として扱われる。
普段はあまり意識しなくていいだろうけど、要注意だ。
しかし、Unicode、なぜこんなことになってしまったのかねぇ。
2012-03-28
jQueryをページの最後にロードのススメ
「Stop paying your jQuery tax」を読んだ。
スクリプトをページの最後で読み込むべき理由
Best Practices for Speeding Up Your Web Site の Put Scripts at the Bottom によれば、
ページの読み込み速度を重視するなら、スクリプトはページの最後に配置すべき。スクリプトは、並列ダウンロードの妨げになるらしい。
複数のホスト名から画像を読み込むようにすれば、ダウンロードの並列度を上げることができる。しかし、ブラウザはスクリプトを読み込んでいる間は、それ以外のダウンロードを開始しない。
だから、スクリプトはページを表示し終わった後に読み込むべきというわけだ。
jQueryをヘッダからフッタに移動する方法
.ready() を使うためだけに jQuery をヘッダで読み込んでいる場合は、その機能だけを自分で作ってしまえばいい。
方法は、Stop paying your jQuery tax で紹介されている。簡単なので、試してみてはどうだろうか。