我想将多个文件复制到闪存驱动器上，以便每个单独的文件都是连续的。它们不需要彼此连续，并且可以按任何顺序排列。这些文件将非常大——数百兆字节到千兆字节。驱动器上的其他文件不应进行碎片整理；这样做会浪费时间并导致闪存介质不必要的磨损。
我希望至少能够对 FAT32 执行此操作，但*nix文件系统的方法也将受到赞赏。
本质上，有两种方法：
- 复制文件并对其进行碎片整理。
- 为每个文件整理足够的连续可用空间，然后将每个文件复制到其位置。
第二个选项通常比第一个选项快得多，并且可以避免对闪存介质造成不必要的磨损，因此第二个选项是非常可取的。
我不介意离线工作的解决方案，但显然在线更好。
答案1
我必须承认我不太明白你想做什么，但我认为这并不重要。我发现这个工具名为defragfswhich ，旨在执行您所要求的操作（如果我理解您要执行的操作）。
http://defragfs.sourceforge.net/index.html
我认为这个工具的特点是它可以进行碎片整理后，我认为您希望基本上保证当您将文件写入磁盘时，它是按顺序完成的。根据 StackOverflow 的问答，标题为：linux下如何将文件存储在连续的磁盘块中，考虑到写入完成的架构，这听起来不可能。
为了完善这个问答，我确实找到了以下听起来可能有用的资源。
答案2
如果您需要在 Linux 上执行此操作：
rsync --preallocate /path/to/source/file /path/to/destination/
rysnc 预分配一个连续的存储块并将文件复制到其中。也适用于 FAT 和 NTFS。
只需确保该文件在目标处尚不存在，否则 rsync 将不会重新分配并重新复制它。如果是，请将其删除，清空垃圾箱以确保它确实消失，然后运行此命令。
验证是否连续复制：
filefrag /path/to/destination/file
“找到 1 个范围”表示文件是连续的。超过一个就意味着它是支离破碎的。
如果仍然存在碎片，请使用filefrag检查源文件是否存在碎片。如果是，请使用rsync --preallocate新名称复制源文件，并对源文件进行碎片整理。然后再次将其 rsync 到所需的目的地。有时，多轮这样可以将源文件和目标文件减少到 1 个范围。
如果此后它仍然碎片，那么目标驱动器上可能没有足够的连续空间来保存完整文件。对整个目标驱动器进行碎片整理，或使用filefrag检查该驱动器上的大文件是否有碎片，并使用 对其进行碎片整理rsync --preallocate，然后重试。
最后，如果您要同步到 NTFS 驱动器，NTFS 会在 3GB 点处为目录文件保留一小部分，如果文件与该 3GB 点重叠，这可能会阻止文件连续。请参阅此处的 Easy2Boot 讨论：
https://easy2boot.xyz/create-your-website-with-blocks/make-using-linux/#Making_files_contigulous
（Easy2Boot 还包括用于从 Linux 对 FAT 和 NTFS 驱动器进行碎片整理的defragfs实用udefrag程序，如果您需要对整个驱动器进行碎片整理，这可能很有用）
答案3
至少对于 FAT32 是可能的，但我不记得该工具的名称了。
如果我没记错的话，是基于第一次调用全长孔并将其分配给新流，然后在该流上读取和写入文件。
如果我没记错的话，也可以通过预分配副本使用 NTFS。
但是，对于 NTFS 压缩文件，没有办法...因为 Windows 首先写入文件（非压缩），然后它以块的形式压缩文件...说实话，它是在管道中执行的...这就是文件变得如此碎片化的原因（10GiB 的文件可以创建超过十万个碎片）。
我不知道有什么工具/命令能够在启用 NTFS 压缩时避免这种情况。我很久以前使用过一个工具，它有一个很好的 GUI，可以在 Windows 中复制而不会造成碎片，但我似乎记不起这个名字了。
所以我能告诉你的最好的办法就是在 Windows 上使用XCOPY带有该/J标志的命令行实用程序。
它会尝试不产生碎片，如果禁用 NTFS 压缩或您使用 FAT32，则非常适合大文件。
NTFS压缩管道碎片说明：
- 块N将被写入集群N上
- N+# 周围的簇将被压缩并存储在其他地方，因此 N 和 N+# 之间的簇将是空闲的，也就是说，文件将被碎片化，非常碎片化。 10GiB = 100000 个片段，假设压缩率为 50%，这就是 NTFS 压缩非常糟糕的原因。如果文件首先在 RAM 上压缩，然后发送到磁盘，则不会出现碎片，或者至少可以避免碎片。
这种做法的另一个副作用是假设我们有 5GiB 的可用空间，而我想写入一个 6GiB 的文件，压缩后只需要 3GiB。这是不可能的，但是如果你先将2GiB（不可压缩）移动到另一个地方，那么可用空间将是7GiB，写入6GiB，压缩使其只有3GiB，可用空间将是4GiB，然后放回原来的2GiB我们移动的数据全部都在那里，并且 2GiB 是免费的。重点是，如果没有足够的空间用于未压缩的文件，则无法在 NTFS 上复制该文件，并且在 NTFS 压缩后是否有足够的空间也没关系。它需要所有这些，因为它首先在不压缩的情况下写入，然后应用压缩。最后，NTFS 驱动程序在管道中执行此操作，因此理论上它仍然是可能的，但它们没有更改检查可用大小部分。
Windows 不会在压缩文件“之后”写入文件，而是在未压缩保存文件之后“压缩”文件，因此对于每个簇，硬盘将看到两次写入尝试，第一次使用非压缩数据，第二次使用压缩数据。现代管道 NTFS 控制器避免 HDD 看到这两个写入，但在第一个 NTFS 版本上，HDD 会以未压缩的方式写入整个文件，然后压缩该文件。对于非常大且可压缩的文件来说，这一点非常明显。写入 NTFS 压缩到仅几个 MiB 的 10GiB 文件（用零填充的文件）比写入该文件的非压缩版本需要更长的时间。如今管道已经打破了这一点，现在只花了很少的时间，但之前足够的可用大小仍然存在。
希望有一天 NTFS 压缩方法能够对一行进行压缩，这样我们就可以获得无碎片的 NTFS 压缩文件，而无需在写入后对其进行碎片整理。在那之前，最好的选择是XCOPY使用/J标志和CONTIG/或我不记得名称的 GUI 工具。当时 Windows 仅支持 XP，并且可以选择暂停、从 HDD1 并行复制到 HDD2、从 HDD3 复制到 HDD4，当然还有预分配。希望这有帮助！
答案4
刚刚发现这个仅适用于 FAT32：