ext3とトランザクション処理
kjournaldによるコミットとチェックポイント ext3では、トランザクションのコミット操作はカーネルスレッドである「kjournald」によって定期的に行われる。kjournaldは、Linuxに実装されているダイナミックタイマと呼ばれる時間管理のためのタイマ機構を利用し、これらのコミット操作が時系列に沿って実行されるようにする。 kjournaldは、カーネルから起動されるとインターバルが5秒ごとに実行されるタイマリストを作成する。個々のトランザクションは、このタイマリストに現在の時刻＋5秒後にコミットが実行されるようにタイマをセットする。kjournaldは5秒置きに起動し、コミットが予定されているトランザクションを登録していた場合は、そのトランザクションをコミットする。ext3では、コミットとチェックポイントはkjournaldの中に一緒に実装されており、コミットが完了するとチ
ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
Why buffered writes are sometimes stalled
Many people think buffered write (write()/pwrite()) is fast because it does not do disk access. But this is not always true. Buffered write sometimes does disk access by itself, or waits for some disk accesses by other threads. Here are three common cases where write() takes longer time (== causing stalls). 1. Read Modify Write Suppose the following logic. Opening aaa.dat without O_DIRECT/O_SYNC,
人間とウェブの未来 - 現状考えうる最良のext3のファイル復元ツールを実装した
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 ext3ファイルシステムの復元の代表的なツールとしてextundeleteがあります。 しかし、extundeleteは「ext3ファイルシステムとファイルの削除・復元について」のエントリにおける正確なファイルの紐付けやその検知ができていません。extundeleteで復元してしまうと、「ext3ファイルシステムとファイルの削除・復元について」で述べた通り、復元対象ファイルのinodeが以前にも違うファイルで使われていて、そのinodeの以前の情報がディレクトリエントリから抽出できてしまった場合、先に見つかったファイル名でinodeの指し示すデータブロックを復元してしまいます。そのため、意図していないファイル名とデータブロックのファイルが復元
ext3ファイルシステムとファイルの削除・復元について
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 研究の一環でext3ファイルシステムのファイル管理方法や、ファイルを削除した時の復元について色々調べたので、それを忘れないように記事にしておこうと思います。 はじめに 今回はext3ファイルシステムについて調査してみました。僕はLinuxでファイルを扱う前提の研究をしているし、大規模環境でのファイルの処理はとても重要だと思っています。 また、ファイルシステムについて理解を深めておく事で、今後新たなネタにならないか等も考えています。現在はext4やBtrfs等の調査が進んでいますが、改めて基本に戻ってext3について調査しました。 まずは、分かりやすいようにext3ファイルシステムでファイルを削除した場合に、どのようにファイル復元ができるのかを
Linuxファイルシステムを最適化する | OSDN Magazine
前回は、一般的なLinuxファイルシステムをいくつか紹介し、それぞれの機能を見ていった。Linuxをすでにインストールしてあれば、パーティションの設定とファイルシステムの構成は済んでいるはずだが、この構成を変更したい場合もあるだろう。最適な方法を探ってみよう。 本稿は、先日刊行された書籍『Linux Power Tools』からの抜粋である。 変更と一口に言っても、中には手間のかかるものもある。たとえば、ファイルシステムを変更するには、バックアップ、新規ファイルシステムの作成、ファイルのリストアという手順が必要になる。ただし、ext2fsからext3fsへの変更だけは例外で、非常に簡単に行うことができる。ファイルシステムを切り替えたら、ファイルシステム作成のさまざまなオプションを利用して、新しいファイルシステムのパフォーマンスを向上させることができる。その他の変更は、比較的簡単だ。ディスク
HowTos/Disk_Optimization
Optimizing the EXT3 file system on CentOS Ext3 is a very capable file system with excellent fault tolerance and a long track record of stability. While it performs well, it's by no means the fastest file system out there. There are some things you can do to give ext3 a boost when you just want speed. Some of the methods listed here will reduce the information kept about your file system as a trade
mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
blog of NiG:NTFS,ext3,ReiserFS等のファイル名の長さの話 - livedoor Blog（ブログ）
ファイル名の長さの制限 概要 NTFS(Windows) : 255文字(UTF-16) ext3(及びUNIXのファイルシステム一般) : 255バイト NTFSとHFS+ではファイル名にUTF-16を使用することが仕様で規定されているが、 Unix系のファイルシステムではファイル名の文字コードの規定はなく、NULL(0x00)と"/"(0x2f)を含まない任意のバイト列が使用できるようになっている。 ASCII文字だけ使うなら上記のどのファイルシステムでも同等だけど、マルチバイト文字を使うとext3の方が使える文字が少なくなる。 今のLinuxは文字コードにUTF-8を採用しているので、日本語は1文字3バイトとなり、255/3=85文字でファイル名のリミットとなる。 ext系 Filesystems HOWTOにてext2でも必要なら1012バイトまで拡張可能という記述があるが、その方
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How Does File Deletion work in Linux
Cloudera Hybrid Data Community
ext3からext4への更新概要
BackupPC