Shred:对Journaled FS不起作用？

Question

碎片文件称碎片"不能保证有效"(见下图).因此,如果我在Ext3文件系统或Raid上粉碎文档,会发生什么？我切碎了部分文件吗？它有时会破坏整个事物,有时不会吗？它可以粉碎其他东西吗？它只会粉碎文件头吗？

注意:请注意,shred依赖于一个非常重要的假设:文件系统会覆盖数据.这是传统的做事方式,但许多现代文件系统设计并不满足这一假设.以下是Shred无效或不保证在所有文件系统模式下有效的文件系统示例:

• 日志结构或日志文件系统,例如AIX和Solaris(以及JFS,ReiserFS,XFS,Ext3等)提供的文件系统

• 即使某些写入失败也会写入冗余数据并继续执行的文件系统,例如基于RAID的文件系统

• 制作快照的文件系统,例如Network Appliance的NFS服务器

• 缓存在临时位置的文件系统,例如NFS版本3客户端

• 压缩文件系统

在ext3文件系统的情况下,上述免责声明仅适用于数据=日志模式(并且除了仅仅元数据之外还记录文件数据)时,应用(并且碎片因此效果有限).在data = ordered(默认)和data = writeback模式中,shred像往常一样工作.可以通过在/ etc/fstab文件中的特定文件系统的mount选项中添加data = something选项来更改Ext3日记记录模式,如mount man page(man mount)中所述.

Answer 1

所有Shred都会覆盖,刷新,检查成功,然后重复.它绝对没有什么可以确定覆盖文件是否实际上导致包含原始数据的块被覆盖.这是因为在不了解底层文件系统的非标准事物的情况下,它不能.

因此,日志文件系统不会覆盖原始块,因为这会阻止它们从更改半写的错误中彻底恢复.如果记录了数据,那么每次碎化都可以写入磁盘上的新位置,在这种情况下,没有任何碎片被撕碎.

RAID文件系统(取决于RAID模式)可能不会覆盖原始块的所有副本.如果存在冗余,则可能会破坏一个磁盘而不会破坏其他磁盘,或者您可能会发现不同的磁盘影响了不同的磁盘,因此每个磁盘都被部分碎片化.

在任何文件系统上,磁盘硬件本身可能恰好检测到错误(或者,在闪存的情况下,即使没有错误也应用耗损均衡)并将逻辑块重新映射到不同的物理块,这样原始块就是标记错误(或未使用)但从未覆盖.

压缩文件系统可能不会覆盖原始块,因为碎片覆盖的数据在每次传递时都是随机的或极其可压缩的,并且任何一个都可能导致文件从根本上改变其压缩大小并因此被重新定位.NTFS在MFT中存储小文件,当碎片将文件大小整理到一个块的倍数时,它的第一个"覆盖"通常会导致文件被重新定位到一个新位置,然后将被无意义地切碎,留下一点MFT插槽未触及.

Shred无法检测到任何这些条件(除非你有一个特殊的实现直接解决你的fs和块驱动程序 - 我不知道是否真的存在这样的事情).这就是为什么它在整个磁盘上使用比在文件系统上更可靠.

在其他文件的意义上,Shred从不撕碎"其他东西".在上面的一些情况中,它会碎片以前未分配的块而不是包含数据的块.它也不会破坏文件系统中的任何元数据(我猜你的意思是"文件头").-u选项会尝试覆盖文件名,方法是重命名为相同长度的新名称,然后在删除文件之前将该字符一次缩短为1个字符.如果指定-v,则可以看到此操作.

Answer 2

其他答案已经很好地解释了为什么 shred 可能无法正常工作。

这可以概括为：

shred 仅适用于分区，不适用于单个文件

如其他答案中所述，如果您粉碎单个文件：

• 不能保证实际数据真的被覆盖，因为文件系统可能会将对同一文件的写入发送到磁盘上的不同位置
• 不能保证 fs 没有在其他地方创建数据的副本
• fs 甚至可能决定“优化”您的写入，因为您正在重复写入同一个文件（同步应该可以防止这种情况，但同样：不能保证）

但即使您知道您的文件系统不会做上述任何令人讨厌的事情，您也必须考虑到许多应用程序会自动创建文件数据的副本：

• 文字处理器、编辑器（如 vim）等将定期写入的崩溃恢复文件
• 文件管理器中的缩略图/预览文件（有时甚至是非图像文件）
• 许多应用程序使用的临时文件

因此，如果没有检查用于处理数据的每个二进制文件，它可能在您不知情的情况下被复制到右侧、左侧和中间。唯一现实的方法是始终切碎完整的分区（或磁盘）。