答案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 位将支持超过 1800 万 TB 的文件）。查找指针文件中的最后一条记录或记录nth或记录last - n，然后查找它在主文件中指向的字节，这将是简单而快速的。特殊文件系统或驱动程序允许的技巧是使此过程原子化并使资源文件透明。
答案4
我想到两个想法：
一些版本控制系统将受控文件的第一个版本完整存储，并将所有后续版本作为更改进行存储；而其他版本控制系统将受控文件的当前版本完整存储，并将所有先前版本作为更改进行存储。
如果您在数据库而不是平面文件中记录运行时事件，那么您可能不清楚数据库是按顺序、反向顺序还是随机存储事件。