Hash 是否有任何常见的操作系统文件系统使用哈希来避免多次存储相同的内容数据？

许多文件存储系统使用哈希来避免重复相同的文件内容数据（除其他原因外），例如Git和Dropbox都使用SHA256。文件名和日期可以不同，但只要内容生成相同的哈希，它就不会被存储多次

为了节省空间，在OS文件系统中这样做似乎是明智的。是否有针对Windows或*nix的文件系统可以做到这一点，或者是否有一个很好的理由可以解释为什么没有一个文件系统可以做到这一点

在大多数情况下，这将消除对重复文件查找工具的需要，因为在这一点上，您将保存的唯一空间将用于文件系统中的文件条目，这对于大多数用户来说并不重要

---

编辑：可以说这可能发生在serverfault上，但我觉得开发人员更容易理解所涉及的问题和权衡。

这会节省空间，但时间成本太高。您提到的产品已经绑定了io，因此哈希的计算成本不是瓶颈。如果在文件系统级别进行散列，所有已经很慢的io操作都会变得更糟。

ZFS从上个月开始支持重复数据消除：

---

虽然我不会将其称为“通用”文件系统（afaik，它目前仅由*BSD支持），但它绝对是一个值得一看的文件系统。

要在文件系统中实现这一点，需要相当多的工作。首先，用户可能正在创建一个文件的副本，计划编辑一个副本，而另一个副本保持不变——因此，当您消除重复时，您以这种方式创建的硬链接必须提供COW语义

其次，文件的权限通常基于文件名所在的目录。您必须确保在创建隐藏的硬链接时，权限是基于链接正确应用的，而不仅仅是实际内容的位置

第三，如果用户在物理上独立的介质上制作（比如）三份文件副本以防止硬件故障导致的数据丢失，然后发现实际上只有一份文件副本，那么当硬件故障时，所有三份副本都消失了，用户可能会感到不安

这让我觉得有点像第二个系统效应——在问题不存在（或至少是物质）很久之后，问题的解决方案。由于目前硬盘驱动器的价格不到100US/TB，我很难相信这会为大多数人节省一整美元的硬盘空间。在这一点上，很难想象大多数人会如此关心。

NTFS已经支持了。

在文件系统（是的，不是您的普通文件系统）中支持（在存储行业就是这样称呼的）一段时间了。这是当今企业文件系统中最重要的功能之一（NetApp之所以突出，是因为它们在自己的系统上支持这一功能，而其他类似产品仅在备份或辅助存储上支持这一功能；它们对于主存储来说速度太慢）

在一个拥有数千用户的大型企业中，重复的数据量是惊人的。许多用户在其主目录中存储相同的文档、源代码等。经常被看到，节约和节约

---

所有这些都意味着，如果您在NetApp文件服务器导出的LUN上创建任何公共文件系统，则无论该LUN中创建了什么文件系统，您都可以免费获得重复数据消除。干杯了解其工作原理。

btrfs

支持在块级别在线重复数据消除。我建议使用一个外部工具。

一个用例是我的一个朋友，他有数千个视频文件，其中许多是同名的重复视频。他正在编写一些代码来散列它们，并找出哪些是相同的视频，这样他就可以删除重复的视频，我突然想到，文件系统可能会为他处理这个问题。我计划构建一个文件服务器，而Solaris正是我的选择，因为ZFS。根据Wikipedia的说法，你可以使用。但你不需要散列所有文件，只有那些与另一个文件大小完全相同的文件…但是你怎么知道还有另一个大小相同的文件？你会将其作为索引存储在文件系统表中吗？然后，添加/更新文件对于支持搜索相同大小的文件会变得昂贵。从技术上讲，您当然可以散列文件并尝试检测重复，但由于io已经是这么多操作的速率限制器，我不确定您是否可以做任何性能足够且仍然100%准确的事情。有趣的是，请阅读Sun的博文（感谢FR）-似乎有一种说法是，性能最终将作为一种权衡，因为磁盘写入已保存，这是我没有想到的。Bashs的存储仍然是一个问题，但假设哈希表适合内存，这可能是真的，假设一台具有大量存储的机器也会有大量内存。很抱歉在我的手机上键入的错误，您知道：）给定一个包含n个大小不同的文件的列表，您可以发现文件大小是否在O（log n）中发生冲突时间使用一个列表，或O（1），如果你哈希键大小本身-它的速度很快，只有当文件大小改变，如新文件，修改。这也不需要在保存时完成，例如，它可以添加到文件系统的待办事项列表中，并在不太忙或文件保存稳定时完成。有趣的是，我不知道COW。第二点似乎并不重要，因为您会忽略内容的位置，所有权限都将基于链接。关于第三点，只在同一个物理驱动器上存储一个副本是有意义的，只要有一个新磁盘（据操作系统所知），就需要一个内容的副本。关于最后一点，这都是文件大小的问题，文件大小在不断增长。我很高兴见到你