filesystems - 在前面截断文件

Question

我最近正在处理的一个问题让我希望我可以去掉文件的前面。有点像“前面截断”，如果你愿意的话。在后端截断文件是一种常见的操作——我们甚至没有考虑太多。但是去掉文件的前面？一开始听起来很荒谬，但这只是因为我们被训练认为这是不可能的。但 lop 操作在某些情况下可能很有用。

一个简单的例子(当然不是唯一的或最好的例子)是 FIFO 队列。您正在将新项目添加到文件的末尾并从文件前面拉出项目。该文件随着时间的推移而增长，前面有一个巨大的空白空间。对于当前的文件系统，有几种方法可以解决这个问题:

删除每个项目后，复制
剩下的项目来替换它，和
截断文件。虽然有效，
这个解决方案非常昂贵
浪费时光。

监控空白空间的大小
前面，当它到达一个
特定大小或百分比
整个文件大小，向上移动所有内容
并截断文件。这是很多
比以前更有效率
解决方案，但仍然需要时间
项目在文件中移动。

实现循环队列
文件，将新项目添加到孔中
文件的前面作为项目是
删除。这可以是相当有效的，
特别是如果你不介意
事情脱离的可能性
队列中的顺序。如果你在乎
关于秩序，有可能
不得不四处移动元素。但在
一般来说，圆形队列很漂亮
易于实现和管理磁盘
空间很好。

但是如果有一个 lop 操作，从队列中删除一个项目就像更新文件开头标记一样容易。事实上，就像截断文件一样简单。那么，为什么没有这样的操作呢？

我对文件系统实现有点了解，并且没有看到任何特殊原因这会很困难。在我看来，它所需要的只是每个分配条目的另一个词(dword，也许是？)来说明文件在 block 内的开始位置。对于 1 TB 的驱动器低于 100 美元，为这种功能付出的代价似乎很小。

如果您可以像在末尾截断一样有效地删除文件的前面，那么还有哪些任务会变得更容易？

你能想到这个功能不能被添加到现代文件系统的任何技术原因吗？其他非技术原因？

Answer 1

在前面截断文件似乎不太难在系统级别实现。

但也有问题。

第一个是在编程级别。在随机访问中打开文件时，当前的范例是使用文件开头的偏移量来指出文件中的不同位置。如果我们在文件开头截断(或从文件中间执行插入或删除)，这不再是一个稳定的属性。 (虽然从末尾追加或截断不是问题)。

换句话说，截断开头会改变唯一的引用点，这很糟糕。

正如您所指出的，在系统级别上存在使用，但很少见。我相信文件的大多数用途都是一次写入多次读取，所以即使截断也不是一个关键特性，我们可能没有它可以做到(有些事情会变得更加困难，但没有什么是不可能的)。

如果我们想要更复杂的访问(并且确实需要)，我们以随机模式打开文件并添加一些内部数据结构。这些信息也可以在多个文件之间共享。这将我们引向我看到的最后一个问题，可能是最重要的问题。

从某种意义上说，当我们使用具有某种内部结构的随机访问文件时……我们仍在使用文件，但我们不再使用文件范例。典型的此类情况是我们想要执行插入或删除记录而不关心它们的物理位置的数据库。数据库可以使用文件作为低级实现，但出于优化目的，一些数据库编辑器选择完全绕过文件系统(想想 Oracle 分区)。

我看不出为什么我们不能用数据库作为数据存储层的文件来完成目前在操作系统中完成的所有工作的技术原因。我什至听说 NTFS 在其内部与数据库有许多共同点。操作系统可以(并且可能在不久的将来)使用另一种范式而不是文件范式。

总而言之，我认为这根本不是技术问题，只是范式的改变，删除开头绝对不是当前“文件范式”的一部分，但不是一个足够大和有用的改变来迫使改变任何东西。