我知道rsync
使用--remove-source-files
(我使用它而不是mv
这样我可以合并目录层次结构)创建新的 inode:
stat 2021_07_30_20_18_17.pdf~
rsync --remove-source-files 2021_07_30_20_18_17.pdf~ 2021_07_30_20_18_17.pdf~.moved
stat 2021_07_30_20_18_17.pdf~.moved
Device: 805h/2053d Inode: 4850411 Links: 1
Device: 805h/2053d Inode: 4849693 Links: 1
由于它正在分配一个新的 inode,这是否意味着它为目标文件分配了新空间?还是--remove-source-files
只是让新的 inode 指向原始文件的内存位置?
背景
我问的原因是因为我的驱动器非常慢,因为目录层次结构很大,大小文件混合在一起),我猜这会使碎片变得更糟。由于大多数 Linux 文件系统不会出现碎片,因此没有像 Windows 上那样简单的碎片整理工具。
我知道我可以 rsync 到一个新驱动器以减少碎片,但是同一个驱动器呢?从内存分配的角度来看,文件移动的工作方式是否相同?
rsync 总是在双进程模式下运行——仍然有一个“发送者”进程和一个“接收者”进程(只是父进程的一个分支),通过套接字对交换数据,就像它们通过网络进行通信一样。这意味着即使是本地复制/移动仍然涉及读取整个原始文件,将其流式传输到 rsync 接收器进程,并将其全部写入新文件。
(这种架构是rsync 特有的,不一定适用于其他工具。例如,
cp A B
甚至cat A > B
不保证会完成完整复制——他们可能会完整复制数据,但他们也可能故意要求文件系统将现有数据链接到新文件。然而,目前 ext4 根本不支持这样的链接;基于“reflink”的副本仅存在于 Btrfs 和 XFS 中。因此,此时
cp A B
ext4上的 a 将生成完整副本。)他们做1,并且有工具 - e2fsprogs(官方的 ext4 工具集)有
e4defrag
,btrfs-progs 也有btrfs fi defrag
,等等。1不像 FAT16/FAT32 那样多(ext2 的设计部分是为了避免以前的 Linux“ext”文件系统曾经存在的碎片问题),但这并不意味着它们以某种方式完全避免碎片,甚至显着比 NTFS 更重要。特别是,任何类型的“写入时复制”文件系统(例如 Btrfs或 ZFS或 NILFS)在文件被覆盖时都会被设计成严重碎片化。