我有一个备份脚本，可以动态生成tar 把它管到mbuffer。然后将数据写入磁带机（LTO3）
我发现mbuffer减慢了带宽，我无法弄清楚原因。
这里有2个命令和低于它们的平均速度
$tar -b 512 -cf - /data | \
mbuffer -A "..." -P 90 -m 1G -f -o /dev/st0 -d 512
in @ 21.8 MB/s, out @ 21.8 MB/s, 1287 MB total, buffer 100% full
如果我再次将数据传输到dd，将导致更高的带宽
$tar -b 512 -cf - /nas/homes/ /nas/photo/ | \
mbuffer -P 90 -m 1G | \
dd of=/dev/st0 bs=256k
in @ 72.9 MB/s, out @ 64.0 MB/s, 2671 MB total, buffer 99% full
我的问题是，如果我以错误的方式使用mbuffer，或者它不应该与-d一起使用。
即使我没有用-d指定块大小，速度也保持不变。
我想使用mbuffer因为-A标志，但是这个性能需要三倍的时间。
答案 0 :(得分：1)
好吧，从mbuffer（1）手册页：
-d use block-size of device for output (needed for some devices, slows output down)
但是，我认为关键是在你的第二个命令中，你使用262144字节（256k）写入，并且在第一个命令中只使用512字节写入。我怀疑你是否将第二个命令更改为bs = 512并将第一个命令更改为-d 262144，以便反转情况。
所以，尝试使用mbuffer -d 262144。
答案 1 :(得分：1)
-d不是选项，您可以指定参数；它用于获取默认大小。要改写，建议您删除-d并以字节为单位使用-s
例如
-s 512000
或使用1024 * 512 = 524288
答案 2 :(得分：0)
我相信LTO会使用至少512的块大小，如果有内存，则不会使用256。尝试使用最小8mb的缓冲区-您会获得更好的结果。
错误地使用dd会在这些驱动器上引发大约3个不同的错误，尤其是在磁带还原期间。记录您使用的方法。以后您可以节省数小时的头痛。
'mt / dev / setblk 512'可以用来克服这个问题（mt-st包），但是-存在用于可变块大小的用途，例如在使用dump / restore（ext4最好）或磁盘归档（而不是磁带存档。
Lzip不会相应地拆分。如果您的数据“应”合适，就很好了。
似乎缺少“长期数据安全”存储方法。焦油不是曾经被破解的东西。 reel2reel很好-不再是了。这些天没有“完整性”，也没有办法跳过坏文件，而且通常不会使用可以做到的方法，或者是在操作系统安装后实施/设置的真正PITA。不幸的是，没有“它就是可行的”解决方案。那就是磁带的本质。磁盘存档（DAR）是Tar的不错替代品-但要耐心等待-请勿破坏WORM磁带上的标头写入-这是修复恢复的真正痛苦。
LTFS只会使事情变得更糟，而不是更好。不要仅仅为了“文件系统”而跳到LTO4 +。在Linux上（正确）进行操作很痛苦。