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

Posted 2023-02-23

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

【英文标题】：Do any common OS file systems use hashes to avoid storing the same content data more than once?

【发布时间】：2010-12-26 13:57:09

【问题描述】：

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

为了节省空间，这似乎是在 OS 文件系统中做的明智之举。是否有任何适用于 Windows 或 *nix 的文件系统可以执行此操作，或者它们是否有充分的理由不执行此操作？

这将在很大程度上消除对重复文件查找器实用程序的需要，因为此时您将节省的唯一空间将用于文件系统中的文件条目，这对于大多数用户来说是不够的问题。

编辑：可以说这可能是服务器故障，但我觉得开发人员更有可能理解所涉及的问题和权衡。

【问题讨论】：

一个用例是我的一个朋友，有成千上万个视频文件，其中许多是不同名称的重复视频。他正在编写一些代码来对它们进行哈希处理并找出哪些是相同的视频，这样他就可以删除重复的视频，我突然想到文件系统可以为他处理这个问题。

【参考方案1】：

ZFS 从上个月开始支持重复数据删除：http://blogs.oracle.com/bonwick/en_US/entry/zfs_dedup

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

【讨论】：

我计划构建一个文件服务器，而 Solaris 正是我的选择，正是因为 ZFS。

根据***，您可以使用ZFS on Linux。

【参考方案2】：

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

【讨论】：

但是您不需要对所有文件进行哈希处理，只需对与另一个文件大小完全相同的文件进行哈希处理...

但是你怎么知道有另一个相同大小的文件？你会把它作为索引存储在文件系统表中吗？然后添加/更新文件变得昂贵以支持搜索相同大小的文件。从技术上讲，您当然可以散列文件并尝试检测重复项，但由于 io 已经是这么多操作的速率限制器，我不确定您是否可以做任何性能足够且仍然 100% 准确的事情。跨度>

有趣 - 只需阅读 Sun 的博客文章（感谢 FR） - 似乎声称由于保存的磁盘写入，性能最终会成为一种权衡，这是我没有想到的。 bashes 的存储仍然是一个问题，但假设哈希表适合内存，这可能是正确的，假设具有大量存储空间的机器也将具有大量内存。

抱歉打错字了 - 你知道在我的手机上打字:)

给定一个包含不同大小的 n 个文件的列表，您可以使用列表查找文件大小是否在 O(log n) 时间内发生冲突，或者如果您对大小本身进行哈希键处理，则为 O(1) - 它是快速，仅在文件大小更改时使用，例如新文件，修改。这也不需要在保存时完成，例如它可以添加到文件系统的待办事项列表中，并在不太忙或文件保存稳定时完成。

【参考方案3】：

NetApp 现在在WAFL 文件系统（是的，不是您的通用文件系统）中支持deduplication（这就是它在存储行业中的名称）few years。这是当今企业文件系统中最重要的功能之一（NetApp 脱颖而出，因为他们在primary storage 上支持此功能，与其他仅在备份或辅助存储上支持它的类似产品相比；它们太慢了用于主存储）。

在拥有数千名用户的大型企业中重复的数据量是惊人的。许多这些用户在他们的主目录中存储相同的文档、源代码等。经常看到Reports of 50-70% data deduplicated，保存lots of space和tons of money for large enterprises。

所有这一切意味着，如果您在由 NetApp 文件管理器导出的 LUN 上创建任何通用文件系统，那么无论在该 LUN 中创建什么文件系统，您都可以免费获得重复数据删除。干杯。了解它是如何工作的 here 和 here。

【参考方案4】：

NTFS 有single instance storage。

【讨论】：

谢谢，从这里blogs.techrepublic.com.com/datacenter/?p=266 发现“单实例存储也将包含在 Windows Server 2008 中，但仅限于存储版本。该功能不会在其他版本中提供。”它也在 Exchange 中实现。

在下一个版本的 Exchange 中它已经消失了。不过它也在Windows Home Server中实现，也就是Win2003下面。

【参考方案5】：

btrfs支持块级数据在线去重。我推荐duperemove，因为需要外部工具。

【参考方案6】：

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

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

第三，如果用户在物理上分开的媒体上制作（例如）三个文件副本以确保不会因硬件故障而丢失数据，用户可能会感到不安，然后发现实际上只有一份文件的副本，所以当硬件出现故障时，所有三个副本都消失了。

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

【讨论】：

有趣，我不知道 COW。第二点似乎无关紧要，因为您会忽略内容的位置，所有权限都将基于链接。关于第三点，只有在同一个物理驱动器上存储一个副本才有意义，只要有一个新磁盘（据操作系统无论如何都可以告诉），就需要内容的副本。

最后一点，这完全是文件大小的问题，文件大小在不断增长。有这个选项会很好，尤其是。由于文件系统的内容可能很快会跨越云，因此在 xfer 时间上的计算权衡是值得的（比如 Dropbox）。

1.编辑如何产生影响？当你写一个文件时，你检查它是否已经存在。如果没有，则编写它并将散列添加到内存中的散列表中。简单的。 2.当然权限是存储在FAT中的，与内容是分开的。 3. 当然，您只能在单个驱动器上执行此操作，而不是跨驱动器。