level@qcloud:~$ cat cloud.txt
$ echo 128 | sudo tee /sys/block/sdb/bdi/read_ahead_kb
128
$ time lz4 -c < /dev/sdb2 > /dev/null
real 0m25.977s
user 0m2.104s
sys 0m1.220s
$ time lz4 -c < /dev/sdb2 > /dev/null
real 0m26.217s
user 0m2.221s
sys 0m1.126s
$ echo 20480 | sudo tee /sys/block/sdb/bdi/read_ahead_kb
20480
$ time lz4 -c < /dev/sdb2 > /dev/null
real 0m22.859s
user 0m0.654s
sys 0m0.491s
$ time lz4 -c < /dev/sdb2 > /dev/null
real 0m22.808s
user 0m0.695s
sys 0m0.428s
$ echo 128 | sudo tee /sys/block/sdb/bdi/read_ahead_kb
128
$ time lz4 -c < /dev/sdb2 > /dev/null
real 0m25.532s
user 0m1.629s
sys 0m1.142s
$ dd if=/dev/sdb2 bs=16M iflag=direct|lz4 -c > /dev/null
记 录 了 32+0 的 读 入
记 录 了 32+0 的 写 出
536870912 字 节 （ 537 MB ，512 MiB ） 已 复 制 ，22.9 s ，23.4 MB/s
level@qcloud:~$
level@qcloud:~$

从这个数据看，这个 read ahead 是有效的。只能说是 page cache 的行为有些奇怪。

@codehz 在你这场景下，加 dd 那必须更慢，瓶颈在 CPU 就得减少 CPU 的开销才会快。两个 dd 的好处，一个 dd 去取数据到内存，一个 dd 负责吐数据给压缩器，取数据的 dd 不用等压缩器，压缩器不用等磁盘。当然了，你这测试环境肯定是加了比不加还慢

@codehz 你在 qemu 中还不开 kvm ，数据基本上没啥意义，因为瓶颈在 CPU ，连 IO 速度也被 CPU 给限制了

@codehz 如果不加 dd 就直接 gzip 更快，那是因为瓶颈在 CPU ，没有 dd 意味更少的进程调度开销自然更快。并且加 dd 一般是要加两个 dd 才会起到缓冲预读的效果。

$ time dd if=/dev/sdb bs=80M status=progress|dd ibs=8M obs=80M|lz4 -c | dd of=/dev/null bs=2M
31611420672 字节 (32 GB, 29 GiB) 已复制，391 s ，80.9 MB/s
输入了 376+1 块记录
输出了 376+1 块记录
31611420672 字节 (32 GB, 29 GiB) 已复制，391.608 s ，80.7 MB/s
输入了 0+482352 块记录
输出了 376+1 块记录
31611420672 字节 (32 GB, 29 GiB) 已复制，391.695 s ，80.7 MB/s
输入了 0+424343 块记录
输出了 0+424343 块记录
27642280069 字节 (28 GB, 26 GiB) 已复制，391.697 s ，70.6 MB/s

real 6m31.704s
user 0m27.970s
sys 1m28.536s
$ lz4 -c < /dev/sdb | dd of=/dev/null bs=2M status=progress
27642280069 字节 (28 GB, 26 GiB) 已复制，465 s ，59.4 MB/s
输入了 0+424180 块记录
输出了 0+424180 块记录
27642280069 字节 (28 GB, 26 GiB) 已复制，465.335 s ，59.4 MB/s

没挂文件系统下的二次读:

$ dd if=/dev/sdb of=/dev/null bs=2M count=1024
输入了 1024+0 块记录
输出了 1024+0 块记录
2147483648 字节 (2.1 GB, 2.0 GiB) 已复制，27.1303 s ，79.2 MB/s
$ dd if=/dev/sdb of=/dev/null bs=2M count=1024
输入了 1024+0 块记录
输出了 1024+0 块记录
2147483648 字节 (2.1 GB, 2.0 GiB) 已复制，26.6422 s ，80.6 MB/s
$ dd if=/dev/sdb of=/dev/null bs=2M count=100
输入了 100+0 块记录
输出了 100+0 块记录
209715200 字节 (210 MB, 200 MiB) 已复制，2.85232 s ，73.5 MB/s

挂文件系统下的二次读：
$ dd if=/dev/sdb of=/dev/null bs=2M count=100
输入了 100+0 块记录
输出了 100+0 块记录
209715200 字节 (210 MB, 200 MiB) 已复制，2.77269 s ，75.6 MB/s
$ dd if=/dev/sdb of=/dev/null bs=2M count=100
输入了 100+0 块记录
输出了 100+0 块记录
209715200 字节 (210 MB, 200 MiB) 已复制，0.0475682 s ，4.4 GB/s

之前一直想搞某个功能，结果就是在这个地方搞不下去了。从这个数据结果看，我不认为 readahead 跟 page cache 生效了。至于你说的代码，我没看过。

@codehz 大概率你的盘已经挂了文件系统。不可能有 readahead 的。你可以试试看，第二次对 sda 读会变成对内存读了。

预读是依赖于 page cache ，而没挂文件系统的 block device 压根就没有 page cache 。

@codehz 请你认真看文档说明
read_ahead_kb (RW)
Maximum number of kilobytes to read-ahead for filesystems on this block device.

这是异步调用。你是没有办法在单线程的 nodejs 直接转成同步调用的。要么多线程，要么去 hack 到 nodejs ，要么就只能继续异步调用。当然了，你可以换其他同步调用的实现

@duke807 其实 fstrim 之后再压缩大小也差不多，就是有些磁盘不支持 trim

这里的裸本来就是特指裸，而你得把它变成专用名词

@codehz 没有挂着的磁盘就是没有预读功能。你不信我也没办法

@codehz 预取是文件系统提供的功能，甚至 page cache 都是跟文件系统挂钩的。没有 mount 文件系统的磁盘就是裸设备。没人会在 mount 分区可写下去做这种全盘备份吧，内核可没有义务保证这种情况下的一致性。

你说他们这个没有参数的用法等价于直接直接 gzip -c /dev/block ，确实是这样。但是你说引入 dd 没有意义我不赞同，基本上很少有人不带参数的直接使用 dd 。印象中，不是所有的硬件都支持硬件预取的，一般也不会去调整它。

@codehz 谁跟你说 dd 啥参数都不戴了。这场景下，你操作的是裸设备不存在预读一说。这就是 bs=16k 跟 bs=16M 速度可以差很远的原因。

@codehz 你觉得毫无价值，那是因为你对 IO 理解的不够。磁盘是低速设备，而 gzip 是 CPU 密集操作，直接操作块设备就会直接绕过文件系统的预读功能，所以在 gzip 跟磁盘之间引入 dd 可以间接引入预读，减少 gzip 读盘的等待时间。

这里是具体的
www.tomshardware.com/how-to/kvm-over-ip-raspberry-pi

可以看 usb 视频采集卡，usb OTG 的 usb gadget 硬件成本大概 200 来块。当然了，也可以自己买现成的方案比如向日葵的控控，比如 kvm over ip ，还有 Intel 的 v pro 。

libvird+virt-manager+qemu-kvm 或者 virtualbox 或者 VMware 。不过你是 Linux 套 Linux ，其实用 lxc 也可以，就是换不了内核。