「エナジードリンクとアルコールを混ぜた飲料を青年期に飲むと脳機能が損なわれる」と題した論文が、科学誌のNeuropharmacologyに掲載されました。論文を発表したのはイギリスの研究チームで、レッドブルを用いた実験によって「エナジードリンクとアルコールを混ぜた飲料」が脳にもたらす影響が確かめられています。
⇧ 何と言うか、「レッドブル」のイメージ悪化は避けられない感じですかね...
まぁ、「レッドブル」以外のエナジードリンクも同様なのかもしらんけど...
Linuxのinodeとは
Wikipediaによると、
inode（アイノード）は、ext2などのUnix系ファイルシステムで古くから使われているデータ構造である。inode にはファイル、ディレクトリなどのファイルシステム上のオブジェクトに関する基本情報が格納される。
ReiserFSなどの最近のUnix系ファイルシステムでは inode を使用していないが、同等の機能を提供するには同等の情報をどこかに格納しなければならない。statシステムコールがそれらのデータをプログラム向けに提供するので、これを statデータと呼ぶことがある。
⇧ とある。
Linux系のOS（Operation System）におけるファイルシステムの根幹のような感じですかね？
とりあえず、
概要
Linuxでは、このようなデータのカーネルでのメモリ上の表現を struct inode と呼ぶ。BSD系システムでは vnode と呼ぶが、この vnode の v はカーネル内の 仮想ファイルシステム層から来ている。
⇧ Wikipediaの「POSIX」のページの情報を確認した感じ、Linuxディストリビューションのほとんどが、
⇧ とあるので、Linuxのファイルシステムについても、inodeの仕組みが取り入れられてるのではないかと。
inode という用語はブロックデバイス上の inode も意味し、通常ファイルやディレクトリや場合によってはシンボリックリンクにも対応している。この概念は破損したファイルシステムのリカバリにおいて特に重要である。
inode 番号は、その inode が記録されているデバイス上で一意の整数値である。全てのファイルは inode に物理的にリンクされている。プログラムがファイルをファイル名で参照するとき、システムはそのファイル名に対応する inode を検索する。
statシステムコールはファイルの inode 番号やその他の inode 内の情報の一部を得る機能である。
⇧ inodeが破損したら、ファイルの情報も取得でき無さそうではある。
まぁ、
⇧上図の仕組みが今いち良く分からんのだけど...
Linuxのinodeとファイル数の上限の関係とか
で、ネット上の情報を漁っていたところ、
⇧ 上記サイト様によりますと、ディスク容量に空きがあったとしても、「inode」の領域に空き容量が無いと、ファイル、または、ディレクトリを作成することができない事象が起こるらしい。
そして、ファイル数が多過ぎる場合の弊害として、
⇧ 処理時間の遅延がありますと。
後は、
⇧ ファイル削除しても、別プロセスが掴んでると、ディスク容量が空かないんだとか...
ファイルにアクセスする際に、排他制御を明示的に行う必要があるそうな...
保守・運用とかの対応で、シェルスクリプトとかで削除せざるを得ない状況だと、排他制御を厳密に行う必要があるということですかね...
オンプレミス環境だと、データベースのバイナリログとか蓄積していきそうですからな...
ちなみに、
まとめ
- xfsでもinodeは枯渇する！
xfs_growfs -m <割り当てパーセント> <デバイス>でinodeの領域を増やせ！
⇧ とあり、ファイルシステムが変わっても、「inode」の問題は、依然として起こり得ると...
ちなみに、Microsoft Copilotに、「RHEL（RedHat Enterprise Linux）」のバージョンと「ファイルシステム」の関係について確認した感じでは、
| OS | ファイルシステム | |
|---|---|---|
| バージョン | サポート | デフォルト |
| RHEL 9 | XFS, ext4, NFS, SMB, Stratis | XFS |
| RHEL 8 | XFS, ext4, NFS, SMB, Stratis | XFS |
| RHEL 7 | XFS, ext4, NFS, SMB | XFS |
| RHEL 6 | XFS, ext4, NFS | ext4 |
⇧ という回答が返ってきたんだけど、信憑性はゼロなんよね...
ネット上で、
⇧ まとめてくださっている情報があり、サポートしてる「ファイルシステム」が、Microsoft Copilotの回答と噛み合わないところを見るに、おそらく、Microsoft Copilotがまた嘘付いてるんだろうな...
こういうマトリックス表については、公式であるRedHatが公開してくれると情報が錯綜しなくなる気がするんですけどね...
RedHatに限らないけど、確認しないといけないドキュメントが多ければ多いほど、利用者側の負担が増えるので、ドキュメント公開側で配慮してもらえるとありがたいんですがね...
何て言うか、利用者側がドキュメントの整理をせざるを得ない状況になっているのは、どう考えても違和感しか無いんだが...
生産性向上について、ソフトウェア開発においては、改善される兆しが見られないような...
毎回、取っ散らかってるドキュメントの該当箇所を探し続けなければいけないという不毛な作業をしないで済むようにしたいのだけど、そんな世界線が訪れることは無さそうですね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
