いった情報を保持している。FATファイルシステムにおいては、ファイルに対応したクラスタにはファイルの中身のみが格納され、ファイル名などのファイルのメタ情報は、ディレクトリエントリ上に全て保持される形となっている。立ったディレクトリエントリとして記録される。ディレクトリ名などのサブディレクトリのメタ情報は、ファイルと同様にディレクトリエントリ上に全て保持される。指すクラスタに格納されるため、ここからこのボリュームのディレクトリツリーを辿ることができる。Nameディレクトリエントリが固定長、あるいは32バイトと聞いて不思議に思われたかもしれない。ファイル名は32バイトを優に超える文字列長になり得る。名前のために割り当てられた空間は11バイトしかない。して区別しており、互換性を保つために涙ぐましい方法でディレクトリエントリのシーケンスにファイル名情報を含めている。これの解説はしんどいので上で紹介したページを参照。MikanOS本でもLFNは省略しているが、SFNしか使えないのはだいぶ哀しいのでorsではLFNの読み取りも実装した。Tableは破損したときの影響が大きいため冗長化されている。個複製されて並んでいる領域となっている。2022/01/27に更新また間が空いてしまった...間に色々やっていた。あるspinlockとsleeplockを共にorsにも実装することにした。ロックの獲得後に割り込みを許可できる。後述のボリュームの読み書きに必要になった。2022/01/27ボリュームセクタのバッファリングxv6でいうバッファキャッシュ層を設けた。スピンロックで排他的に扱う。ボリュームの読み書きは行えない。スリープロックを獲得して必要なボリュームの読み書きを行う。バッファリングされたセクタをまず獲得した上で、読み書きに際してセクタ単位のロックを獲得するようにした。これはパフォーマンス計測等してそうしたというわけではなく、実装上その方が都合が良かった。返却が自動的に行われる。2022/01/29に更新ファイルの読み書きができるように。非常にI/Oが遅い...が、逆に思い当たるところがありすぎる。何よりも遅いのはブロックデバイスの読み書きだろう...リクエストキューに一つリクエストを積むたびレスポンス待ちで実行コンテキストを止めている。他、ファイルシステム実装のレベルではFATを毎回先頭から探索しているのも非常に効率が悪い。そもそもFATは全部メモリキャッシュしても良さそうだ。設計の面でも、並行した操作に対する安全性だとかエラーへの耐性だとかの考慮が全然出来ていない。FATファイルシステムの仕様上不可能なこともあるが、このファイルシステムで実現出来る限界のレベルにも遠い。自作言語でもそうだったが、それ以上に、自作OSでは様々な領域の実装を扱うので、「最低限実装する」から「ある程度使えるよう実装する」まで持ち上げるのも非常に大変だなあとか思う。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。