質問の続き私尋ねられたスタックオーバーフローデータが上から下ではなく、「端から前」または「下から上」に書き込まれるファイル システムは存在しますか?
具体的には、ログファイルを最新のものから順に保存する方法（おそらく専用のもの）を探しています（ア・ラブログやニュース サイトがどのように整理され、最新のものが上に表示されるかなど)。
そのような獣は存在するのでしょうか? もし存在するなら、それは何であり、どこにいるのでしょうか?
答え1
あなたが求めているのは、単に「逆」ファイルシステムではありません。レコード構造、「逆」ファイルシステム、つまり最後に追加されたレコードがファイルの最初に表示されるレコード ファイルシステムです。実際、逆の側面はおそらく「最初の既存のレコードの前にレコードを挿入できる」として実装されます。
PC に一般的に搭載されているオペレーティング システム (Unix、Windows、さらに特殊なもの) のファイル システム インターフェイスはバイト構造のみで、レコードの概念はありません。そのため、残念ながら使用できません。
1 つの方法としては、各ログ エントリをディレクトリ内の別のファイルにすることです。次に、ファイルの作成時刻の逆順にディレクトリをトラバースします。ログ エントリに単調に増加する名前を付ける場合は、名前の逆順にトラバースします。ログ エントリの数は多くなる可能性が高いため、大きなディレクトリを適切にサポートするファイル システムを使用するか (たとえば、Linux では、このdir_index機能を備えた reiserfs と ext3 は問題ありませんが、ext2 は問題があります)、サブディレクトリを使用します (最初の 1000 エントリ用に 1 つ、次の 1000 エントリ用に 1 つ、など)。
もう 1 つの方法としては、より洗練されたデータベース (SQL でクエリを実行できるデータベースなど) を使用し、作成順とは逆の順序でレコードを選択するという方法があります ( SELECT message FROM logs ORDER BY date DESC)。
答え2
まったく存在しないとは言い切れませんが、聞いたことはありません。もしそれが可能であれば、大きなデメリットがあると思います。
ファイルの先頭に追加するには、通常、既存のデータの完全なコピーが必要です。ファイル システムでは、ファイルの先頭にブロックを追加するだけで済むかもしれませんが、それでもいくつかの小さな問題が発生します。空き領域のあるブロックは先頭に空き領域を保持する必要があるため、適切な場所を見つけるためにドライブによる追加のシークが必要になる可能性が高くなります。
逆方向に作業する場合、ドライブの空き領域の処理が非常に面倒になります。最大インデックスを見つけて、そこから逆方向に作業する必要があるため、ほとんどのプログラミング手法と矛盾します。
大きなファイルでは速度が低下するだろうし、プログラミングするのは間違いなく馬鹿げたことだろうと想像できます。
逆ファイルシステムを探す代わりに、単にファイルを通常通りに書き込んで逆順に解析すればいいのではないでしょうか。基本的なメッセージフォーマットスキームを作成し、ファイルを読み取り、そこからメッセージを解析して、最後から最初の順に表示します。最後のメッセージだけが必要な場合は、ファイルの最後までシークしてから戻ります。んメッセージ。同様の結果が得られますが、作業ははるかに少なく、パフォーマンスは同等かそれ以上になります。
答え3
アイデアを分離する必要があるストレージそして検索あなたが言及したブログでも、エントリはおそらく保存された時系列順に並べると、表示された逆時系列順（構造化ストレージを使用することで容易になるという事実は無視します）。
おそらく、固定長フォーマットのリソース ファイルに格納されたバイト オフセット ポインターを持つ自由形式および可変長の「レコード」を使用して、エントリを通常の順方向順序で格納する、単純な構造化ストレージ システムを作成することができます (64 ビットでは 1,800 万テラバイトを超えるファイルがサポートされます)。ポインター ファイル内の最後のレコードまたはレコードnth、last - n次にメイン ファイル内のそのレコードが指すバイトを検索するのは、簡単で迅速です。特別なファイル システムまたはドライバーで実現できるトリックは、これをアトミックにして、リソース ファイルを透過的にすることです。
答え4
2つの考えが思い浮かびます。
バージョン管理システムの中には、管理対象ファイルの最初のバージョンを完全に保存し、それ以降のすべてのバージョンを変更として保存するものもあれば、管理対象ファイルの現在のバージョンを完全に保存し、それ以前のすべてのバージョンを変更として保存するものもあります。
実行時イベントをフラット ファイルではなくデータベースに記録する場合、データベースがイベントを順番に格納しているのか、逆順に格納しているのか、無作為に格納しているのかが不明瞭になる可能性があります。