gpt4 book ai didi

linux - Shred:不适用于 Journaled FS?

转载 作者:IT王子 更新时间:2023-10-29 00:04:16 28 4
gpt4 key购买 nike

Shred 文档说 shred “不能保证有效”(见底部)。因此,如果我在我的 Ext3 文件系统或 Raid 上粉碎文档,会发生什么?我是否切碎了文件的一部分?它有时会撕碎整个东西,有时不会吗?能撕碎其他东西吗?它只切碎文件头吗?

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file sys‐ tem modes:

  • log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

  • file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems

  • file systems that make snapshots, such as Network Appliance’s NFS server

  • file systems that cache in temporary locations, such as NFS version 3 clients

  • compressed file systems

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount).

最佳答案

shred 所做的只是覆盖、刷新、检查成功和重复。它绝对不会查明覆盖文件是否真的会导致包含原始数据的 block 被覆盖。这是因为在不了解有关底层文件系统的非标准信息的情况下,它无法做到这一点。

因此,日志文件系统不会覆盖原先的 block ,因为这会阻止它们从更改写入一半的错误中完全恢复。如果记录数据,则每次粉碎都可能写入磁盘上的新位置,在这种情况下,不会粉碎任何内容。

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

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

压缩的文件系统可能不会覆盖原始 block ,因为每次通过粉碎覆盖的数据是随机的或极度可压缩的,并且任何一个都可能导致文件从根本上改变其压缩大小并因此被重新定位。 NTFS 在 MFT 中存储小文件,当 shred 将文件大小四舍五入到一个 block 的倍数时,它的第一个“覆盖”通常会导致文件被重新定位到一个新位置,然后将毫无意义地切碎,留下小MFT 插槽未受影响。

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

切碎从不切碎其他文件意义上的“其他内容”。在上面的某些情况下,它会粉碎以前未分配的 block ,而不是包含您的数据的 block 。它也不会粉碎文件系统中的任何元数据(我猜这就是你所说的“文件头”的意思)。 -u 选项确实会尝试覆盖文件名,方法是重命名为相同长度的新名称,然后在删除文件之前一次将一个字符缩短为 1 个字符。如果您也指定 -v,您可以看到实际效果。

关于linux - Shred:不适用于 Journaled FS?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/913282/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com