GitHub - tripflex/inodes: Bash/Shell script to count inode usageYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ブロックアルゴリズムとB-Treeアルゴリズム
後で説明するが、ext2ではブロックグループ0の「スーパーブロック」に、パーティション内のブロックグループ全体の管理情報が格納される。 スーパーブロックには、 iノードの総数 ブロックサイズ ファイルシステムのサイズ 空きブロック数、空きiノード数 使用されているブロックグループ 最終fsck時刻 など、ファイルシステムに関するさまざまな情報が含まれている。「グループディスクリプタ」は、「データブロックビットマップ」や「iノードビットマップ」情報などを参照して空きブロックや空きiノードを探し、データを割り当てる際に最適なブロックを決定するのに使われる。 「データブロックビットマップ」と「iノードビットマップ」は、ビットマップ情報である。ビットマップ情報は、あるデータが使用中か未使用かを0か1のbitで保持している。1byte＝8bitsなので、80個のブロックの状態を10bytesで管理で
UNIXのinode番号 - 中年SEのありふれた生活
inode番号を理解する UNIXファイルシステムで使用するシンボリックリンク（または、ソフトリンク、symlinkなど）はとっても便利なファイルです。Windowsのショートカットファイルに似ていますね。 このシンボリックリンクファイルに｢出会ってよかった！」って思います。 特に、システム構築時に各ファイル、ディレクトリの配置を設計する人は、よく理解しておくことをお勧めします。 でも、その前に。。。 UNIXのファイルシステムの特徴、inode番号、ディレクトリの仕組みをざっくり理解しないと、なかなか難しいかもしれません。 ls-lの結果はinodeの情報 UNIXのファイルシステムでは、１つのファイルを、データ部分と属性部の2つから構成して管理します。 Linuxでは、この属性部のことを、inodeと呼んでいます。 このinodeもハードディスクに書き込まれています。データ以外にこのi
ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
Linuxのpipeの実装を見てみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Unix V6のpipe()と比べてLinuxのpipe()どう実装しているんですかねーなんて話を最近したのでちょっと見比べてみた。 V6のpipeははじめてのOSコードリーディング 読書会 (15)でやったところなんだけど、俺は風邪ひいて家で引きこもってたので・・・ V6のpipeの挙動は大体こんな感じ。 pipeはルートディスクのストレージ領域を4096B（8ブロック）使用し実現する 4KBのデータ領域はひとつのファイルとして扱われる（inodeが割り当てられる） オンメモリではなくてストレージを経由するが、バッファサイズが小さいのでブロックデバイスのバッファキャッシュが効きやすいようになっている pipeの受け手がデータを読みだす前に他の優先度の高いプロセスがブロックデバイスを使用するとキャッシュが効かなくなる可能性あり でも、データはストレージに書かれているので内容が壊れると言った
そのファイル、安全に更新できていますか？（アトミックなファイル操作：前編）
ハートビーツ最年長エンジニアの滝澤です。以前、弊社CTOにシニアおっさんエンジニアから若手エンジニアに向けて何か書いてくれと言われた気がしたので、アトミック（atomic）なファイル操作について3編に分けて紹介します。この内容は弊社の社内勉強会で話した内容をまとめ直したものです。 そのファイル、安全に更新できていますか？（アトミックなファイル操作：前編）←今回 そのファイル、安全に作成できていますか？（アトミックなファイル操作：中編） そのファイル、安全にロックできていますか？（アトミックなファイル操作：後編） 今回は「みなさん、安全にファイルの更新ができていますか？」ということについて、考えてみましょう。 あなたはあるサーバ上のファイルの更新を依頼され、もらったファイルをサーバ上でコピーして上書きしました。しばらくして、データに異常が発生したので調べて欲しいと言われました。さて、何が起き
ext3ファイルシステムとファイルの削除・復元について
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 研究の一環でext3ファイルシステムのファイル管理方法や、ファイルを削除した時の復元について色々調べたので、それを忘れないように記事にしておこうと思います。 はじめに 今回はext3ファイルシステムについて調査してみました。僕はLinuxでファイルを扱う前提の研究をしているし、大規模環境でのファイルの処理はとても重要だと思っています。 また、ファイルシステムについて理解を深めておく事で、今後新たなネタにならないか等も考えています。現在はext4やBtrfs等の調査が進んでいますが、改めて基本に戻ってext3について調査しました。 まずは、分かりやすいようにext3ファイルシステムでファイルを削除した場合に、どのようにファイル復元ができるのかを
Ext2 FS - Linuxカーネルメモ
パーティション全体に関する情報を持つ。 ・i-node数 ・ブロック数 ・空きブロック数 ・空きi-node数 など。 通常はブロックグループ0のスーパーブロックがプライマリとして使用される。他のブロックグループにあるスーパーブロックはバックアップとして使用される。ただし、全ブロックにバックアップがあるわけではない。 (Ref. to man dumpe2fs, man e2fsck, ext2_fs.h::struct ext2_super_block) ブロックグループ内に関する情報を持つ。 ・ブロックビットマップ領域のブロック番号 ・ i-nodeビットマップ領域のブロック番号 ・i-nodeテーブル領域のブロック番号 ・空きブロック数 ・空きi-node数 など。 自分のブロックグループに対するディスクリプタだけでなく。パーティション内の全ブロックグループのブロックディスクリプタが
logrotateがプロセスにHUP送る理由を調べてみた - カイワレの大冒険 Third
2016/07/04追記: 当時はこれで試行錯誤していましたが、本当はlogrotateのソースコードを読んで理解すべきだと思います。あとカーネルね。若者が試行錯誤していたのだと、温かい目で見て頂ければと思います。 詳解Linuxカーネル第3版 Linux 2．6対応 [ ダニエル・P．ボベット ]posted with カエレバ楽天市場で探すAmazonで探す - ちょっと気になる症状があって、どう追うのがよいのか分からなかったんでけど、呟いたら色々ご意見もらったので、その調査ログ。 メモに残してから随分時間かかってしまった… まだ整理しきれていない部分があるので、あとで続き書くかも。多分。 ご意見・ご指摘あったら是非宜しくお願いします。 発端 発端は、logrorateが走るタイミングでrsyslogにHUPが送られるんだけど、どういう挙動になるのか、なぜそのHUPが必要なのかを追いた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How Does File Deletion work in Linux