@feitxue 这说明跟驱动没有关系吧。大概率这两个机器即使换成 window 10 也无法正常使用这个硬盘盒。

贴主所谓的识别是指啥？指能自动挂载么。USB 设备，一般不会碰到识别不了的情况。你应该试试 lsusb 然后 cat /proc/partitions 看看。如果都能看到，估计是没有文件系统驱动原因。

可以手动下载 archive.ubuntu.com 的包然后手动安装，我试过 Ubuntu 18 可以安装 5.19 的 kernel 包。不过如果报依赖关系就只能试试 apt source 下载新版本号的源代码，然后编译，这个方法我试过在 Ubuntu 18 上安装 ccache 4.6

其实两家公司都算错了。正确的算法是不应该有歧义，也就是不管是反算正算，结果一样。

@hzj629206
转接头图片:
https://item.jd.com/10032940933962.html
数据线
https://item.jd.com/100017986276.html
然后两个拼接在一起，就是成一条公对公的线了。

至于能不年能用双头 type-c 的线+转接头，插入电脑的 type-c 口来用(应该是可以的)，或者是用刚刚的数据线倒插连接电脑的 type-c 与盒子的 type-c(大概率不可以)，没有试过。

你的使用 sendmsg 的 api ，然后在 msghdr 指定 scm_txtime 。然后 queue 也需要配置

这么搞太费劲了，应该是直接植入看门狗。没按时喂狗就直接原地爆炸，什么健康码扫描全免了。

@ltkun 驱动没法直接用，因为 coreelec 是 64bit 的，而 slimbox 是 32bit 的，并且内核版本也不一样。不过固件是通用的，nvram 也是可以直接用。不过驱动一般有开源的，可以自己试试编译。如果是闭源就没法，只能用原来的固件

@codehz dd 用做缓冲在 shell 里本来就很常见

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 ，要么就只能继续异步调用。当然了，你可以换其他同步调用的实现