ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
ファイルの変更を監視して、任意のコマンドを実行するスクリプト - （ひ）メモ
d:id:hirose31:20070528:1180326347 のobserve-mtimeは、ファイルのmtimeの変更を定期的に確認してイベントを発火させてたんですが、それをLinuxのinotifyで置き換えてみました。 mtime監視だと調べてスリープしての繰り返しなので、変更してからイベントが起こせるまでちょっとタイムラグがあったんですが、inotifyを使うとファイルが変更された瞬間にぴこっとイベント発火できるのでこっちのほうがいいかも。 http://www.linux.or.jp/JM/html/LDP_man-pages/man7/inotify.7.html rsync + inotify = lsyncd | スラド デベロッパー Linux::Inotify2 CPANにはLinux::Inotifyというのもあったのですが、$Config{archname}が
Google File System(GFS)技術メモ — ありえるえりあ
* 参照した論文 + http://labs.google.com/papers/gfs-sosp2003.pdf * 特徴 + 安いPC(OSはGNU/Linux)で分散ファイルシステムを構築しています(*注1)。 + PCは壊れるという前提で設計しています(*注2)。このため、分散システムを構成するノードが壊れた時、データが失われないことと、自動で復旧できることに主眼を置いています。 + ファイルシステムを利用する側(アプリ)に、ある程度の想定を求めています。任意の利用ケースに対してそこそこのパフォーマンスを出す(=平均的に良い性能)のではなく、特定の利用ケースで性能を発揮できるように設計しています。 + 性能を発揮できる利用ケースは次のようなケースです。 ++ 主にサイズの大きいファイルを扱う(*注3)。 ++ ファイルへの書き込みは追記(append)が多い(ファイルの一部分を何度
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
