答案1
您所要求的不僅僅是一個“反向”檔案系統。你想要一個記錄結構，「反向」檔案系統，即最後新增的記錄首先出現在檔案中的記錄檔案系統。事實上，相反的方面可能會實現為「您可以在第一個現有記錄之前插入一筆記錄」。
通常在 PC（Unix、Windows 甚至更奇特的作業系統）上找到的作業系統中的檔案系統介面只是位元組結構的——它們沒有記錄的概念。所以你運氣不好。
一種可能的方法是使每個日誌條目成為目錄中的單獨檔案。然後按檔案建立時間的相反順序遍歷目錄，或者如果為日誌條目指定單調遞增的名稱，則按名稱的相反順序遍歷目錄。由於您可能有大量日誌條目，因此要么確保使用支援大型目錄的檔案系統（例如，在 Linux 上，具有該dir_index功能的 reiserfs 和 ext3 可以，但 ext2 不行），或者使用子目錄（一個前1000 個條目，後1000 個條目，依此類推）。
另一種方法是使用更複雜的資料庫，例如可以在 SQL 中查詢的資料庫，並且只需按照建立時的相反順序選擇記錄 ( SELECT message FROM logs ORDER BY date DESC)。
答案2
我不完全確定不存在，但我肯定從未聽說過。如果能做到的話，我想會有一些重大的缺點。
在文件前面添加通常需要現有資料的完整副本。在檔案系統中，您也許可以透過在檔案開頭新增一個區塊來處理它，但它仍然會導致一些小問題。具有可用空間的區塊必須在開始時保留可用空間，因此很可能需要驅動器進行額外的查找才能找到正確的位置。
當向後工作時，處理驅動器上的可用空間將成為一個主要的痛苦。它與大多數程式設計技術相矛盾，因為您必須找到最大索引，然後從那裡返回。
我可以想像它會減慢大檔案的速度，而程式設計肯定是一件荒謬的事情。
與其尋找反向檔案系統，為什麼不能像往常一樣簡單地編寫檔案並反向解析它呢？制定基本的訊息格式化方案，讀取檔案並從中解析訊息，然後從後到先顯示它們。如果您只需要最後一條訊息，請查找文件末尾，然後返回n消息。它會產生類似的結果，但工作量要少得多，並且性能可比或更好。
答案3
你需要將這些想法分開貯存和恢復。即使在您提到的部落格中，這些條目也可能是已儲存按時間順序排列，但是顯示的按時間倒序排列（忽略使用結構化儲存會變得更容易的事實）。
人們可以想像創建一個簡單的結構化儲存系統，該系統將按照熟悉的前向順序儲存條目，其中包含自由格式和可變長度的“記錄”，並且位元組偏移指標以固定長度格式儲存在資源文件中（64 位將支援超過 1,800 萬 TB 的文件）。尋找指標檔案中的最後一筆記錄或nth記錄或記錄last - n，然後它指向主檔案中的位元組將是簡單而快速的。特殊檔案系統或驅動程式允許的技巧是使其原子化並使資源檔案透明。
答案4
我想到了兩個想法：
一些版本控制系統完整儲存受控文件的第一個版本以及所有後續版本作為更改，而其他版本控制系統則完整儲存受控文件的當前版本以及所有先前版本作為更改。
如果您將執行時間事件記錄在資料庫而不是平面檔案中，則您可能不清楚資料庫是否按順序、逆順序或隨意儲存事件。