切丝：不适用于日志FS？ [英] Shred: Doesn't work on Journaled FS?
问题描述
注意：shred依赖于一个非常重要的假设：
文件系统覆盖数据到位。这是
传统的做法，但许多现代文件系统设计
不能满足这个假设。以下是文件
系统的示例，其中shred不起作用，或者不能保证在所有文件系统模式下都是
有效：
日志结构化或日志文件系统，例如AIX和Solaris提供的那些文件系统（以及JFS，ReiserFS，XFS，Ext3等）。 b $ b
- 创建快照的系统，如Network Appliance的NFS服务器
写入冗余数据的文件系统，即使有些写入失败也会继续执行，例如基于RAID的文件系统
在临时位置（如NFS版本3客户端）缓存的文件系统
压缩文件系统
对于ext3文件系统，以上免责声明仅适用于
（因此碎化因此效率有限）仅在data = journal
模式下，除了元数据以外还记录文件数据。在
中，data = ordered（默认）和data = writeback模式，shred
照常工作。 Ext3日志模式可以通过在/ etc / fstab文件中的
特定文件系统的
data = something选项中加以更改，如
mount手册页man mount）。
所有碎片都是覆盖，刷新，检查成功，并重复。它完全不知道是否覆盖文件实际上导致包含原始数据的块被覆盖。这是因为不知道底层文件系统的非标准事情，它不能。
因此，日志文件系统不会覆盖原始块，因为会阻止他们从变化被写成一半的错误中彻底恢复。如果数据被记录，那么每一个碎片的通过可能被写入磁盘上的一个新的位置，在这种情况下，没有任何东西被撕碎。
RAID文件系统（取决于RAID模式）可能不会覆盖原始块的所有副本。如果有冗余，你可能会撕碎一个磁盘而不是其他磁盘，或者你可能会发现不同的磁盘会影响到不同的磁盘，这样每个磁盘都被部分切碎。
在任何文件系统上，磁盘硬件本身可能只是碰巧检测到错误（或者在闪存的情况下，即使没有错误也应用损耗平衡），并将逻辑块重新映射到不同的物理块，使得原始被标记为有故障（或未使用），但从未被覆盖。
压缩的文件系统可能不会覆盖原始块，因为碎片覆盖的数据是随机的或者是非常可压缩的通过，任何一个可能会导致文件从根本上改变其压缩大小，因此被重新定位。 NTFS将小文件存储在MFT中，并且在将文件大小整理为一个块的倍数时，其第一次覆盖通常会导致文件被重新定位到新的位置，然后将其毫无意义地撕碎， MFT槽未触及。
碎片检测不到任何这些条件（除非你有一个特殊的实现，直接解决你的FS和块驱动程序 - 我不知道是否任何这样的事实际上都存在）。这就是为什么在整个磁盘上使用它比在文件系统上更可靠。
在其他文件的意义上，碎片从来不会撕碎其他东西。在上面的一些情况下，它将先前未分配的块而不是包含数据的块分解。它也不会撕碎文件系统中的任何元数据（我猜这是你的意思是文件头）。 -u选项会尝试覆盖文件名，通过重命名为相同长度的新名称，然后在删除文件之前，一次缩减一个字符，最多为1个字符。如果你指定-v，你可以看到这个。
Shred documentation says shred is "not guaranteed to be effective" (See bottom). So if I shred a document on my Ext3 filesystem or on a Raid, what happens? Do I shred part of the file? Does it sometimes shred the whole thing and sometimes not? Can it shred other stuff? Does it only shred the file header?
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).
All shred does is overwrite, flush, check success, and repeat. It does absolutely nothing to find out whether overwriting a file actually results in the blocks which contained the original data being overwritten. This is because without knowing non-standard things about the underlying filesystem, it can't.
So, journaling filesystems won't overwrite the original blocks in place, because that would stop them recovering cleanly from errors where the change is half-written. If data is journaled, then each pass of shred might be written to a new location on disk, in which case nothing is shredded.
RAID filesystems (depending on the RAID mode) might not overwrite all of the copies of the original blocks. If there's redundancy, you might shred one disk but not the other(s), or you might find that different passes have affected different disks such that each disk is partly shredded.
On any filesystem, the disk hardware itself might just so happen to detect an error (or, in the case of flash, apply wear-leveling even without an error) and remap the logical block to a different physical block, such that the original is marked faulty (or unused) but never overwritten.
Compressed filesystems might not overwrite the original blocks, because the data with which shred overwrites is either random or extremely compressible on each pass, and either one might cause the file to radically change its compressed size and hence be relocated. NTFS stores small files in the MFT, and when shred rounds up the filesize to a multiple of one block, its first "overwrite" will typically cause the file to be relocated out to a new location, which will then be pointlessly shredded leaving the little MFT slot untouched.
Shred can't detect any of these conditions (unless you have a special implementation which directly addresses your fs and block driver - I don't know whether any such things actually exist). That's why it's more reliable when used on a whole disk than on a filesystem.
Shred never shreds "other stuff" in the sense of other files. In some of the cases above it shreds previously-unallocated blocks instead of the blocks which contain your data. It also doesn't shred any metadata in the filesystem (which I guess is what you mean by "file header"). The -u option does attempt to overwrite the file name, by renaming to a new name of the same length and then shortening that one character at a time down to 1 char, prior to deleting the file. You can see this in action if you specify -v too.
这篇关于切丝：不适用于日志FS？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
