把一堆 GameCube 和 Wii 镜像塞进一块 2TB 硬盘是我这几年反复折腾的事情。原始 ISO 一个就 1.35GB 或 4.7GB几十个游戏下去硬盘直接被吃掉大半还得留空间放存档、录像和临时文件。后来换成 RVZ 格式情况才真正改观——Dolphin 模拟器自带的 RVZ 容器配合 zstd 压缩和 scrub能把一份原始镜像的体积砍掉七成上下。但真正让我花时间琢磨的不是要不要转 RVZ而是转换对话框里那个不起眼的下拉框块大小。它默认 128KiB看起来像个无关紧要的参数实际决定了压缩率能不能再挤出几个百分点、模拟器读盘会不会出现解压抖动、以及同一份镜像在不同硬盘上跑起来体感是否一致。这篇内容就是把这套调优逻辑讲透RVZ 到底省了什么、块大小在压缩率和读盘延迟之间怎么权衡、不同场景该怎么选参数、批量转换的脚本怎么写、以及我踩过的那些坑。适合已经会装 Dolphin、手上有自己备份镜像、想把归档做得更讲究一点的人纯新手也能看懂因为我会先把基础概念捋一遍。1. RVZ 到底省了什么先把70%这个数字算清楚1.1 一个镜像的体积都花在哪了先说个反直觉的事实一张 Wii 单层光盘标称 4.7GB准确说是 4,699,979,776 字节但你真正需要的游戏数据往往只有 1.2GB 到 1.8GB 之间。剩下那接近 3GB 的空间不是空的是被填充数据占满了。光盘时代这么做的原因很实在——把数据铺开到盘片外圈可以减少寻道距离、降低主轴电机反复变速带来的发热和噪音同时也能掩盖某些区域读取速度偏慢的物理特性。所以厂商在打包时会把一部分看起来有内容、实际没人读的扇区塞进去。这些填充数据有两种典型形态。一种是纯零填充肉眼可见的大段 0x00另一种是所谓垃圾数据内容随机但确实占扇区。对模拟器来说这两种都是纯粹的存储浪费——游戏逻辑永远不会去读它们。除了填充另一块开销来自数据本身的冗余同一张贴图的多个 mipmap 层级、多语言版本的重复资源、音频流里相似度极高的连续帧这些在未压缩状态下都是按原样存储的。所以存储效率提升 70%这个说法本质是两件事叠加的结果第一丢掉没人读的扇区scrub第二把剩下的有效数据用 zstd 压一遍。前者贡献了大头后者再补上十几个百分点。弄明白这个来源很重要因为后面调块大小时你会发现块大小能优化的只是第二件事里的一个零头别指望它把 70% 变成 85%。1.2 RVZ 容器的三层结构要理解块大小为什么会影响压缩率和读取性能得先知道 RVZ 内部是怎么摆放数据的。按我对格式文档和实际文件结构的理解一个 RVZ 文件大致分三块文件头记录魔数、格式版本、原始镜像总大小、使用的压缩算法、压缩级别以及最关键的——块大小。这个值写在头里读取时必须严格匹配改了就对不上。原始数据区raw data存放那些不能压缩、或必须按原始偏移访问的部分。典型的是 Wii 分区表、文件系统元数据所在的首批扇区、以及某些需要被随机寻址的关键结构。这部分体积很小通常是几 MB 到几十 MB。分组数据区group data是体积的主体。有效数据被切成固定大小的分组每个分组内部再切成若干个块块是独立压缩单元。每个块前面有一个小小的块头记录压缩后长度和原始长度如果整块全是零会被打上特殊标记几乎不占空间——这也是为什么纯填充区域压缩效果极其夸张。文件尾部还有各分组的哈希用于完整性校验。这里就出现了关键约束块大小必须能整除分组大小。RVZ 的分组大小是固定的所以我实践下来可用的块大小都是一串 2 的幂32KiB、64KiB、128KiB、256KiB、512KiB、1MiB、2MiB。超出这个范围或者不是 32KiB 整数倍的取值工具会直接报错拒绝。默认给的是 128KiB属于谁都不出错的中间值但不是每个场景的最优解。1.3 三种口径别被标题带偏提升 70%这句话如果脱离参照物很容易被误读。我按自己的实测习惯把它拆成三种口径你对照自己的情况看属于哪一种口径参照物典型缩减幅度说明口径一完整未处理的原始 ISO65% - 80%最常被引用的数字scrub 贡献最大口径二已经 scrub 过的镜像20% - 35%只剩压缩算法的功劳口径三默认参数的 RVZ3% - 8%纯粹是块大小和压缩级别调优的增量绝大多数人说提升 70%讲的是口径一也就是第一次从 ISO 转成 RVZ 时看到的体积变化。而这篇要聊的深度调优实际瞄准的是口径三——在已经转成 RVZ 的基础上通过块大小和压缩级别的组合再往下压那么几个百分点同时不把读盘体验搞坏。我特意强调这一点是因为见过太多人把期望值放错了位置以为把块大小从 128KiB 拉到 2MiB 能省一半空间结果发现只省了 20MB然后觉得调优没用。实际上调优的价值不在于省那点空间而在于在体积、转换耗时、解压延迟三者之间找到适合你设备和玩法的那个平衡点。一个天天玩的游戏为了省 15MB 让每次场景切换多等 200 毫秒这笔账怎么算都不划算。2. 块大小到底在调什么压缩率与读盘延迟的跷跷板2.1 块是解压的最小单位也是随机读取的放大倍数这句话是整个调优的核心值得反复咀嚼模拟器想读 1 个字节也必须把整块解压出来。块大小是 128KiB读 4KiB 的数据就要解压 128KiB放大 32 倍块大小是 2MiB同样读 4KiB 就要解压 2MiB放大 512 倍。当然实际情况没这么夸张因为模拟器不是傻读。Dolphin 在读盘模拟这一层有自己的缓存和预读策略游戏加载时也通常是连续大块读取——过场动画、场景切换、地图加载动辄几百 KB 到几 MB 连续往下读。这种顺序访问模式下块越大反而越划算一次解压能服务后续好几次读取摊销下来开销很低。真正会被放大的是那些零散的小读取查文件系统、读配置、播放循环音效时反复跳转。这些请求如果每次都落在不同的块上解压开销就实打实付出来了。所以判断块大小合不合适不能只看平均读取速度得看你的游戏是哪种访问模式占主导。注意这里的放大倍数是逻辑上的不代表真的会多花那么多时间。解压本身是纯 CPU 计算zstd 的解压速度非常快几百 MB/s 是常态。真正的瓶颈通常出现在 CPU 单核性能弱的设备上或者同时有其他负载的时候。2.2 块越大压缩率越高的原因zstd 这类基于 LZ 的算法核心思路是在输入数据里找重复的字节序列把后面的替换成往前 N 个字节复制 M 个字节这样的短指令。输入的连续区间越长能找到的重复模式就越多尤其是那些跨扇区、跨文件的相似结构。举个具体的例子一张 512×512 的贴图它和它的一半尺寸版本、四分之一尺寸版本在 mipmap 链里是挨着放的像素数据高度相似但不完全相同。如果这几个版本恰好落在同一个块里压缩器能大量复用前面出现过的模式如果被块的边界切开后面的部分就得从零开始建模压缩率立刻掉下来。音频流也是同理连续帧之间的波形差异很小块越大越容易吃到这个红利。但这种收益是递减的原因在 zstd 的窗口大小上。压缩器能回头看的范围是有限的超出窗口的历史数据就参考不到了。当块大小超过窗口尺寸再增大块也不会带来明显收益只是把一堆本来就压不动的数据凑在一起。这就是为什么从 32KiB 提到 256KiB 能省 3%从 1MiB 提到 2MiB 只能省 0.5%。压缩级别也会影响这个关系。级别越高zstd 用的窗口越大、搜索越深大块的优势才越能体现出来。级别 5 配 2MiB 块和级别 19 配 2MiB 块收益完全不是一个量级——但后者慢得让人怀疑人生这点后面细说。2.3 换算一下128KiB 块在不同介质上的真实代价光讲原理没意思我拿几个具体数字感受一下。假设某个游戏在加载界面要读 64KiB 的数据块大小 32KiB解压 2 块总解压量 64KiB无浪费。块大小 128KiB解压 1 块如果数据没跨块解压量 128KiB浪费 64KiB。块大小 2MiB解压 1 块解压量 2MiB浪费约 1.94MiB。看着 2MiB 块很吓人但要放在整体里看。一次场景加载通常要读几十 MB2MiB 块的浪费摊薄到几百次读取里占比不到 1%而它带来的压缩率提升可能让整个文件小 5%顺序读取的字节数反而更少。这就是为什么块越大越慢这个结论在顺序读取为主的场景下根本不成立。反过来如果游戏频繁做小读取——比如某些 RPG 在地图上走两步就查一次资源表——那 2MiB 块的表现就会明显劣化。我在一台老笔记本上试过同一款游戏分别用 128KiB 和 2MiB 块运行前者切换地图基本无感后者偶尔能察觉到半秒左右的卡顿。所以这事没法一刀切必须结合设备和游戏类型。还有一个容易被忽略的因素存储介质本身的随机读性能。机械硬盘的 4K 随机读是灾难级的但它顺序读很快所以大块顺序读对它友好SSD 随机读几乎无成本小块反而更灵活SD 卡和 eMMC 的情况介于两者之间而且很多廉价卡的随机 4K 性能差得离谱这种设备上大块顺序读往往是更稳的选择。这不是 RVZ 本身的特性而是你的文件怎么被读出来这件事的物理基础。3. 动手调优从 GUI 到命令行的完整流程3.1 转换前的准备清单动手之前有几件事必须先确认不然中途出问题会很被动。我按踩坑顺序列一遍原始镜像先验一遍完整性。Dolphin 的镜像列表里能看到每个镜像的校验状态或者右键选择校验。源文件本身有问题转出来的 RVZ 一定有问题而且报错信息往往指向 RVZ让你白折腾半天。预留足够的磁盘空间。转换过程是读源写目标目标文件最大可能接近源文件大小如果压缩效果差稳妥起见预留源文件大小的 1.2 倍并且确认和源文件在同一个分区还是不同分区——跨分区写速度会受限于慢的那一头。关掉正在使用该镜像的模拟器实例。文件被占用时转换会直接失败有时候是静默失败输出一个 0 字节文件很容易误以为成功了。调整电源和休眠设置。批量转几十个游戏可能跑一两个小时中途休眠会打断转换。我吃过一次亏早上起来发现转到 60% 就停了还得重来。记下源镜像的校验值。不用太复杂Dolphin 界面上显示的就行转完之后对比一下能确认处理的是同一个文件。确认自己处理的是合法持有的光盘备份别去碰来源不明的镜像这是基本前提。3.2 GUI 转换三个下拉框分别该怎么选Dolphin 的图形界面转换入口在镜像列表上右键 → Convert File转换文件。弹出的对话框里真正需要你决策的只有三项格式Format选 RVZ。同系列还有 WIA两者结构同源但 RVZ 是后来改进的版本支持更好的压缩算法组合日常归档直接选 RVZ 就行。块大小Block Size默认 128 KiB。下拉框里能选的通常就是 32K 到 2M 这一串。这一步的选择逻辑我放在下一节展开先给个粗暴结论不确定就用 256 KiB兼顾压缩率和读取灵活性几乎所有场景都不会出大错。压缩级别Compression Level默认 5。范围一般到 22但千万别被最大值诱惑。级别 5 到 9 是性价比区间超过 15 之后转换时间会呈指数上升体积收益却只有百分之几。我做过对比同一份 1.6GB 有效数据的镜像级别 5 转了不到 3 分钟级别 19 转了将近 25 分钟省下来 40MB 左右。除非你是要刻到只读介质上长期封存否则这个时间花得不值。转换过程有进度条完成后会自动刷新镜像列表。这时候别急着删源文件先做校验流程在 3.4 节。3.3 命令行批量转换与参数计算GUI 转一两个还行几十个就得靠命令行工具了。Dolphin 安装目录里带了一个命令行工具能做转换、校验、提取等操作。转换的基本命令是这样DolphinTool convert \ -i /data/backup/sample_a.iso \ -o /data/rvz/sample_a.rvz \ -f rvz \ -b 262144 \ -l 5参数含义-i输入文件-o输出文件-f目标格式-b块大小-l压缩级别。重点说-b这个参数的单位是字节不是 KiB这是最容易填错的地方。换算关系想要的值实际要填的数字记忆方式32 KiB3276832 × 102464 KiB6553664 × 1024128 KiB131072128 × 1024256 KiB262144256 × 1024512 KiB524288512 × 10241 MiB10485761024 × 10242 MiB20971522048 × 1024填了个不在允许范围内的数字工具会报参数错误不会静默改成别的值这一点还算友好。不同版本对允许范围可能有细微差异拿不准就先跑DolphinTool convert -h看一眼帮助文本里的说明比猜强。批量处理我用的是一段 Bash 脚本核心思路是遍历目录、跳过已有输出、逐个转换#!/usr/bin/env bash set -euo pipefail SRC_DIR/data/backup DST_DIR/data/rvz BLOCK262144 # 256 KiB LEVEL5 mkdir -p $DST_DIR find $SRC_DIR -maxdepth 1 -type f \ \( -iname *.iso -o -iname *.gcm \) -print0 | while IFS read -r -d src; do name$(basename ${src%.*}) out$DST_DIR/${name}.rvz if [[ -s $out ]]; then echo [skip] $out 已存在 continue fi echo [run ] $name DolphinTool convert -i $src -o $out -f rvz -b $BLOCK -l $LEVEL if [[ -s $out ]]; then echo [ok ] $(du -h $out | cut -f1) $out else echo [fail] $name fi done几个细节值得说。-print0配合read -d 是为了处理文件名里带空格的情况Wii 游戏名里带空格太常见了用普通for循环会直接把文件名切碎。[[ -s $out ]]判断文件存在且非空这样中途断掉留下的 0 字节文件会被重新处理而不是被当成已完成跳过。set -euo pipefail让脚本遇到错误立刻停避免一路错下去生成一堆废文件。如果你想同时维护两套不同参数的版本比如热玩目录用 256KiB、归档目录用 1MiB把BLOCK和DST_DIR抽成脚本参数就行别写死在代码里。3.4 转换后的校验与体积核对转换完成不等于成功这一步千万别省。校验有两个层面容器层面的校验。用工具自带的校验子命令对 RVZ 文件做哈希比对能确认文件内部结构没损坏、各分组的哈希对得上。图形界面里对应的是右键 → 校验完整性。这一步跑完没报错说明文件至少在格式上是自洽的。内容层面的校验。更彻底的做法是把 RVZ 再转回 ISO和原始镜像对比校验值。这么干很费时间和空间我一般只在两种情况下做一是这个镜像特别重要二是之前遇到过疑似数据损坏的问题。日常归档做个容器校验就够了。体积核对是另一件必须做的事。把转换前后的数字记下来ls -l /data/backup/sample_a.iso /data/rvz/sample_a.rvz du -h --apparent-size /data/rvz/sample_a.rvz用--apparent-size是因为某些文件系统会对稀疏文件做压缩或按块统计直接看占用量会得到偏小的数字容易误判压缩效果。同时注意单位工具输出可能是字节、可能是 GiB换算的时候别搞混——1 GiB 1073741824 字节和 1 GB 差了 7% 左右这个差异足够让提升 70%变成提升 65%报数据的时候要统一口径。4. 实测对照表与场景选型建议4.1 同一份镜像、不同块大小的实测数据我拿三个不同类型的样本做了对照都是 Wii 平台转换时压缩级别统一用 5。样本描述我做了脱敏只保留体积特征样本原始镜像有效数据32K64K128K256K512K1M2M样本 A纹理密集4.38 GiB约 1.62 GiB1.191.161.141.121.111.101.10样本 B音频流为主4.38 GiB约 1.28 GiB0.930.900.880.860.850.850.85样本 C小体积1.36 GiB约 0.71 GiB0.550.540.530.520.520.52—单位都是 GiB。几个观察第一从 32K 到 128K 的收益最明显大约 3% 到 5%这一段值得调。从 512K 往上基本是平的2M 相比 1M 几乎没有区别纯粹浪费灵活性。第二实时换算成对原始镜像的缩减比样本 A 从 4.38 GiB 降到 1.12 GiB缩减约 74%样本 B 从 4.38 GiB 降到 0.86 GiB缩减约 80%样本 C 从 1.36 GiB 降到 0.52 GiB缩减约 62%。这就是提升 70%的实际来源——主体收益在 scrub 和格式本身块大小的贡献只有其中三五个百分点。第三样本 C 体积小块大小的影响反而更不明显因为文件总共就那么大块大小再怎么变能利用的重复模式总量有限。所以小镜像别太纠结参数默认值转就行。我还试过一次把压缩级别拉到 19 配合 2M 块样本 A 从 1.10 GiB 降到 1.02 GiB再省 7% 左右但转换时间从 3 分钟变成 26 分钟。除非是转完就封存、三年不开一次的冷备这个交易不划算。4.2 按存储介质和使用场景选参数下面这张表是我这几年总结出来的直接对着抄就行使用场景块大小压缩级别选择理由长期冷备几乎不运行1M - 2M12 - 19体积优先转换慢点无所谓解压延迟不在乎装在主力 SSD 上天天玩128K - 256K5 - 8随机读灵活解压开销小体积损失可接受装在机械硬盘上常玩512K - 1M5顺序读为主大块能减少寻道次数放在移动硬盘或 SD 卡上随身带256K - 512K3 - 5兼顾体积和解压速度低级别解压更省 CPU老机器CPU 单核性能弱64K - 128K1 - 3解压量小、级别低优先保证帧数稳定需要频繁在模拟器和实机间倒腾128K5兼容性最稳遇到问题最容易定位这里有个我自己踩出来的经验别给同一款游戏同时保留多个不同参数的版本。看起来灵活实际上管理成本很高过几个月你根本记不住哪个是哪个还白白占空间。真要做对比测试测完就删只留一个最终版。4.3 把参数写进文件名半年后你会感谢自己批量转换最麻烦的不是转是半年后你想不起来当初用了什么参数。我的办法是直接在文件名后缀里带上关键信息sample_a [rvz256k-l5].rvz sample_b [rvz1m-l12].rvz中括号里rvz是格式、256k是块大小、l5是压缩级别。这样不用打开任何工具看文件名就知道参数。配合前面那个批量脚本只要在输出路径的拼接里改一行把这个后缀加进去就行out$DST_DIR/${name} [rvz${BLOCK_SLUG}-l${LEVEL}].rvz另外建议在归档目录放一个纯文本的记录文件一行一条文件名、原始大小、转换后大小、转换日期、参数、校验状态。这种土办法比任何工具都可靠尤其是你换了机器、重装了系统之后。5. 踩坑记录与排查速查表5.1 转换中断、验证失败、模拟器报错转到一半停了输出文件是 0 字节或者明显偏小。最常见的三个原因磁盘满了、机器休眠了、源文件被模拟器占用。排查顺序是先看磁盘剩余空间再看系统日志里有没有休眠记录最后确认没有 Dolphin 实例在跑。处理办法很简单删掉残缺输出重新转脚本里那个-s判断就是为这种情况准备的。转换成功但校验报错。先别怀疑工具九成是源镜像本身有问题。可能是之前用别的方式处理过、下载不完整、或者存储介质有坏块。拿原始镜像跑一次校验如果源就不过那跟 RVZ 没关系。转换后在模拟器里打开黑屏或卡在加载界面。这种情况很少见但确实存在。RVZ 会丢弃未被文件系统引用的扇区极个别游戏会去读那些按理说不该读的区域读到全零就和原始镜像行为不一致了。判断方法很简单把原始 ISO 放回去跑一遍如果正常基本可以确认是这个问题。处理办法就是这款游戏继续用 ISO或者用不 scrub 的模式转换。别为了统一格式硬转兼容性优先。游戏能跑但偶尔音频卡顿、场景切换掉帧。大概率是块太大加上 CPU 单核性能不足解压抖动被放大了。把块大小降到 128K压缩级别降到 5 以下重新转一份对比通常能改善。如果还是不行那可能跟块大小无关去查图形后端和音频后端设置。转换后体积反而比原来大。两种可能源文件本来就是处理过的精简镜像没有多少冗余可压或者你用了很小的块配很低的级别压缩效率还不如不压。遇到这种情况直接放弃转换原样保留更划算。5.2 常见问题速查表现象最可能的原因处理方式报块大小参数无效不是 32KiB 整数倍或超出允许范围查帮助文本改用 32768 到 2097152 之间的 2 的幂命令跑完没输出文件路径不存在或没有写权限先mkdir -p建目录检查权限文件名带空格导致处理失败循环没用 null 分隔用-print0配read -d 路径全部加引号批量转换中途退出set -e遇到单个失败就整体停止想跳过失败项就改成记录日志继续别用set -e校验通过但模拟器读不出输出格式选错选成 WIA 等确认-f参数是 rvz转换速度异常慢压缩级别过高或源/目标跨慢速分区降到 5-8 级把源和目标放同一块盘同参数两次转换体积不同工具版本不同算法实现有差异固定工具版本记录版本号移动硬盘上播放过场卡顿块大 硬盘休眠唤醒延迟降到 256K关掉硬盘休眠5.3 几条不出现在文档里的经验别追极限压缩级别。这是新手最容易犯的错。看到级别能拉到 22 就想试试结果一个游戏转半小时省下的体积还不够存一张截图。级别 5 到 9 这段的性价比最高级别 13 以上基本属于仪式感。块大小别一次拉到底。我从 32K 一路试到 2M中间发现 256K 到 512K 是个甜点区再往上收益断崖式下跌。如果你的设备不算弱从 256K 起步觉得卡顿再往下调比从 2M 往下试效率高得多。转换是有 CPU 成本的批量跑要注意散热。几十个大文件连续转机器会长时间满载笔记本尤其容易过热降频转得越来越慢。可以分批跑中间留点间隔或者限制并发数——虽然单线程转换本身不太吃多核但多个进程并行会互相抢资源反而更慢。保留一份原始镜像放在另一块物理盘上。这话听起来像冗余但我真的遇到过归档盘出问题、所有 RVZ 一起完蛋的情况。压缩得再好也比不上还有一份没压过的这份安心。当然前提是空间允许实在没条件就至少把最舍不得的几个留原样。换机器之后重新测一次。同一套参数在不同 CPU 上的表现可能差得很远老机器上跑得顺的 512K换到新机器上可能 2M 都不卡。参数是跟设备绑定的不是跟文件绑定的迁移的时候值得花十分钟重测一遍。最后分享一个我自己反复验证过的小结论对绝大多数人来说RVZ 256KiB 块 压缩级别 5这个组合已经能拿到这个格式能给的九成收益剩下的那一成需要你为自己的设备和游戏逐个个案调投入产出比很低。真正让存储效率从省一半变成省七成的是选择转换这件事本身块大小只是最后的精修。我现在的做法是归档目录统一 1M 级别 9热玩目录统一 256K 级别 5两套并行一年多下来没再动过参数——稳定比最优更重要。
