警告：不要再用Rufus在较新的大容量U盘上制作启动盘

昨天用Rufus4.7p在一个256G的凯侠U盘上制作启动盘，下载了最新的debian13/ubuntu，选择映像，然后开始，之后就把它挂在后台。

过了很久，打开迅游加速器打算玩会儿战舰世界，却发现迅游启动极其缓慢，十几分钟都无法显示完整界面（这显然也有问题，但暂时不管）；查看任务管理器，看不出问题，只是磁盘占用有点高，但所有磁盘写入都低于0.1MB/s。

再一看，U盘占用100%；切换过去一看，每1秒左右一次写入峰，只写500k字节；持续了不知多久。再看Rufus，它竟然只格式化了40%多点！

一个多小时了，它一个格式化进程都搞不定？它究竟在干什么？

这东西完全就是乱来，写这东西的人什么都不懂。它就是名气大，2.x版本打下了名气，大家第一时间想到它而已。

的确，有些uefi/bootloader可能会检查boot sect……但，在MBR时代，那顶天20个扇区，给它全填零直接就完事了；gpt时代顶天100个扇区，填零需要多久？

然后MBR 512字节，gpt略多，填充，写分区表，分区就完成了——我过去天天玩的，再熟悉不过了。

之后文件分配表也一样，按分区表设置，从分区第0扇区开始，建立一个空白文件分配表，把正确大小填写进去，剩下就没什么事了。

所以Linux下直接分两步，fdisk只管分区，fs.ext4之类建立文件分配表；将来调整分区导致容量不对了，一个resize2fs把文件分配表里面记载的分区大小一改，别的统统不用动，直接搞定。

就这么简单点事，它给我全盘全块写一遍？

要知道，SSD写一遍就意味着每一块都要擦除一次！

SSD最怕的其实不是写入，怕的就是擦除，TLC大约500次擦除就废了，QLC更少。

我这个U盘应该是TLC，平常能跑100M以上的写入速度，此时是模拟出来的SLC，占用空间更大但速度达到SLC水平；一旦SLC缓冲用光就成了TLC，速度自然极限降低。

不仅如此，我还怀疑这家伙是按4k字节每扇区在搞，也就是每4k字节写一次，而SSD反应速度是700ms左右，所以才显示500k的写入速度；但SSD往往是16K字节每扇区，这就导致它每次写入都擦除我16K区域，也就是产生了4倍的写放大。

尤其是，它的动作很可能是强制写入然后flush，确保落盘；而这个usb大约700ms以上才能完成一次“擦除-重写”过程！

尤其是，根据deepseek的数据，现在的SSD经常是16K字节一个扇区、每个擦除trunk是1M字节以上！

如果是这样，那么每个扇区它就要触发4次擦除；而擦除并不能只擦除16k字节，而是1M，也就是1024K——换句话说，这里产生的是256倍的写放大！

让它格式化一次，我的U盘最少丢4次擦除寿命，最高则相当于256次全盘写入。TLC的理论寿命是500次，也即是说两次都能把它写报废！

这种高倍率的写放大进一步把U盘性能砍到了极限，读写速度堪比当年的3.5寸软盘——这就是它写入极度缓慢的真相。

因此，如果你也有较新的大容量U盘，如果也发现了它格式化缓慢问题，那么不要再用Rufus制作启动盘。

好用的工具多的是，别再用它了。恶心。

另外，这大概也暴露了“迅游启动时可能有隐蔽的扫描磁盘动作”。不然Rufus折磨我的U盘，它的启动怎么会那么慢？

经分析，这可能是它启动时默认扫描磁盘、以识别新增游戏导致的。而这个扫描恰好遇到Rufus 100%占用了U盘，这才导致它卡在载入界面。

PS：为避免杀毒软件干扰，我在制造启动盘时刻意关闭了实时防护。因此可以确定是Rufus的问题。

又看了下日志。Rufus实际上是在建立一个220G的persistent store分区，这个分区是ext3格式的。因此这个故障不是出在分区和简单格式化阶段，而是在mkfs.ext3阶段；而这个动作它执行的非常的糟糕……

我用yumi昨晚直接做了三次启动盘，第一次先放了个ubuntu24.04 desktop，然后又给它做了40G的persistent store；等放Debian 13 live cd时发现第一个区太小，放不下第二个iso了。于是格掉重做，把256G统统拿来做启动盘，并且给ubuntu和debian各10G的persistent store。

此时执行极快，三个统统做完也不过半小时。包括40G+10G+10G的persistent store，它速度最慢时也保持在6MB/s以上。

只有Rufus，它会迅速进入那种恐怖的“每700ms+一次写入、500kB/s写入速率”的状态，持续两小时都无法完成启动盘制作（我强制中断时仅仅完成了40%）。

而且，Rufus做的启动盘导致Debian不认我的老WiFi，报告没有firmware；而yumi做的直接识别。