@pagxir 有一个非常简单的方法能测试 readahead 有没有生效（
就是把它关闭了
echo 0 > /sys/block/sda/queue/read_ahead_kb
然后再运行 dd if=/dev/sda of=/dev/null bs=1M
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 1.039096 seconds, 15.4MB/s
而设置成默认 128 是这个效果
/ # echo 128 > /sys/block/sda/queue/read_ahead_kb
/ # dd if=/dev/sda of=/dev/null bs=1M
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 0.127543 seconds, 125.4MB/s
而用极为夸张的 1048576 则是这个效果（可见不是越大越好）
/ # echo 1048576 > /sys/block/sda/queue/read_ahead_kb
/ # dd if=/dev/sda of=/dev/null bs=1M
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 0.121848 seconds, 131.3MB/s

（测试中的磁盘是 qemu 参数 -drive file=/tmp/test.img,format=raw 挂载的，qemu 本身没有启用 kvm 模式，因此性能较低但是比较稳定）

此外关于 gzip 管道的问题，我也做了一个测试，当磁盘速度不是瓶颈（且 readahead 没被禁用的情况下）
/ # time dd if=/dev/sda of=/dev/null bs=1048576
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 0.129122 seconds, 123.9MB/s
real 0m 0.14s
user 0m 0.00s
sys 0m 0.13s
直接用 gzip
/ # time sh -c 'gzip -c /dev/sda > /dev/null'
real 0m 0.87s
user 0m 0.76s
sys 0m 0.10s
加个 dd 管道
/ # time sh -c 'dd if=/dev/sda bs=1048576 | gzip > /dev/null'
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 1.008238 seconds, 15.9MB/s
real 0m 1.03s
user 0m 0.79s
sys 0m 0.23s
可见速度反而还下降了（我也测试过其他 bs 值，几乎不对结果产生影响，始终大于 1 秒，这个模拟下 1048576 已经是接近最优的值了）
有趣的是，如果这时候用 dd 的 direct 模式手动绕过缓存
/ # time sh -c 'dd if=/dev/sda bs=1048576 iflag=direct | gzip > /dev/null'
16+0 records in
16+0 records out
16777216 bytes (16.0MB) copied, 0.959065 seconds, 16.7MB/s
real 0m 0.98s
user 0m 0.78s
sys 0m 0.18s
就小于 1 秒了，可惜还是没有 gzip 直接压缩快（

@pagxir 完全没有文件系统，是临时创建全 0 的磁盘镜像，然后 shell 是从 initrd 里来的，也就是从头到尾就没有磁盘被挂载

@pagxir 我建议直接看源码
https://github.com/torvalds/linux/blob/master/block/fops.c#L410-L422 给出了块设备的 readahead 的实现
在 https://github.com/torvalds/linux/blob/master/mm/readahead.c#L157-L176 这个位置下断点，然后开 gdb 调试引导，执行命令 cat /dev/sda > /dev/null ，就可以发现确实用到了这里的 readahead
调用栈是 blkdev_readahead | read_pages | page_cache_ra_unbounded | do_page_cache_ra | page_cache_async_ra | filemap_readahead | filemap_get_pages | filemap_read | blkdev_read_iter | call_read_iter | new_sync_read | vfs_read | ksys_read | do_syscall_x64 | do_syscall_64 | entry_SYSCALL_64
每个函数的含义都可以自己查看，linux 没有魔法，不可能说源码里写了 page cache 还能不用的

@pagxir 要不你解释下 /sys/block/<块设备名字>/queue/read_ahead_kb 这个是放着干啥的（
另外这有一份解释 VFS 和块设备的 ppt
http://devarea.com/wp-content/uploads/2017/10/Linux-VFS-and-Block.pdf
这是 linux readahead 实现的相关代码
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/readahead.c
以及 backing-dev.c filemap.c 等文件里（ filemap 和 filesystem 毫无关联），搜索 ra_pages 就可以找到不少相关实现
除了同名系统调用的实现是在通知 vfs 之外（总不能让用户程序自己算文件在磁盘上的位置吧，所以这部分计算得委托给 vfs 实现），其他部分均与 vfs 无关，readahead 操作就是在块设备层面实现的
你定义里的裸磁盘也就是块设备，当然也会用到这里的 readahead 能力

@documentzhangx66 很抱歉，dd 也只是单纯的用 open + read + seek + write 这四个 api 在做文件操作，除了 iflag 可以多指定一些打开参数之外，没有任何魔法 https://github.com/coreutils/coreutils/blob/master/src/dd.c 除了成片的参数解析代码之外，根本没有你所说的磁盘格式，分区，权限的处理（当然，还是有别的操作的，比如可以做编码转换，但是我相信你不会在备份的时候考虑这个吧），
我相信你肯定会读代码的吧
但是如果不会，可以考虑挂一个 strace 跟踪下到底运行了哪些系统调用，我这帮你列出来好了（除去周围 glibc 的调用，命令是 dd if=/dev/sda of=/tmp/x bs=512 count=1

openat(AT_FDCWD, "/dev/sda", O_RDONLY) = 3
dup2(3, 0) = 0
close(3) = 0
lseek(0, 0, SEEK_CUR) = 0
openat(AT_FDCWD, "/tmp/x", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
dup2(3, 1) = 1
close(3) = 0
read(0, "3\300\216\320\274\0|\216\300\216\330\276\0|\277\0\6\271\0\2\374\363\244Ph\34\6\313\373\271\4\0"..., 512) = 512
write(1, "3\300\216\320\274\0|\216\300\216\330\276\0|\277\0\6\271\0\2\374\363\244Ph\34\6\313\373\271\4\0"..., 512) = 512
close(0) = 0
close(1) = 0

你总不能说 dd 用了神奇的魔法，它既能在源代码中隐藏，也能在 strace 跟踪的时候消失，然后做你所说的那些操作吧）

@pagxir 此外 5.14 内核已经彻底移除裸设备功能，有需要的只能通过 O_DIRECT 参数打开块设备
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093

@pagxir https://tldp.org/HOWTO/SCSI-2.4-HOWTO/rawdev.html 有关裸设备的一些信息

@pagxir (建议复习 linux 基本知识，块设备和裸设备不是一个概念，而且磁盘必然是块设备，裸设备（实际属于字符设备）要手动绑定到块设备上才可以使用（裸设备和分区与否没有任何关系，如果有，一定是有人把 raw disk 翻译成裸设备了）可以参考部分发行版提供的 raw 命令的相关说明
预读显然也是块设备提供的基本功能（不妨看下 blockdev 命令），还有 page cache 也是，你甚至可以直接对块设备进行 mmap 操作

@pagxir 哦，想起来了，你是在混淆裸设备和块设备，但是这里备份的是块设备，特别考虑的分区的话肯定不能是裸的）

@pagxir 楼上不是都没参数的吗？我说 “这个用法” 有错吗？
此外块设备怎么就没预读了，你是不是自己运行了 blockdev --setra 0 /dev/sda 然后忘记了？

@pagxir 谁和你说 dd 会增加缓存的？？相反，你必须在 dd 中指定 iflag=direct 才可以“绕过”页面缓存（同时 bypass 预读），而多数程序实现的读取都不会用 direct io （因为很多文件系统根本不支持，加上通常只会减速，只有数据库这种特殊用例才会主动开选项去用 direct io ，普通程序自然也不会无故增加这种无聊的选项）
而且，如果你不加任何选项，dd 会使用非常小的块作为单位（ 512 字节）进行读取，这显然多数情况都不是最优解（虽然影响也不是很大，只是会增加系统调用频率）

@shijingshijing dd 又不会自动提权，gzip 也不会自己降低权限（ dd 的这个用法根本毫无价值）

所以为啥楼上非得加 dd ，直接 gzip -c /dev/sda1 > xxx.tar.gz 不就好了（
此外 ext4 并没有奇怪的特性导致需要真的全盘备份才能保持，所以可以按文件备份，直接 tar gz 的形式就不错
但是 tar 格式本身其实不太友好——特别是没法随机访问文件，所以可以换个文件系统，例如 squashfs （但是这个压缩比较慢），或者比较新且性能不错的 https://github.com/mhx/dwarfs 这类

@sjhhjx0122 typescript 也不是 javascript 啊（
ts 用 noImplicitOverride 就可以强制覆盖用 override

js 啥时候支持 override 关键词了？

咦 ，
const [content, setContent] = useState()
const [size, setSize] = useState()
useEffect(()=>{
setContent(props.content)
setSize(props.size)
},[content,size])
这是在干啥
用内部的 state 作为 effect 的 deps 参数吗，那肯定不会更新啊（另外推荐开 eslint
直接在 jsx 里用 props 上的属性就可以了

(你不会直接原地 push 到数组的吧

首先先明确一点，复杂度不反映实际情况，它也没必要反映现实，就像你做经典物理题目不应该考虑相对论。
复杂度显然是在抽象机器的模型上的描述，而且不同场景下抽象机器也可以完全不同，所以讨论复杂度的时候，显然要把采用的模型先作为共识，不然只能是鸡同鸭讲，结果自然没有任何意义。
讨论到寻址这一层的时候，自然要选取一个让结果不是常数的机器模型。但是这并不代表在讨论排序算法的时候，也需要用这样的机器模型，这是两件完全不同的事情，关注点根本不一样。

（ win32 的话，其实还有更 cursed 的方法：把目标窗口嵌入到自己窗口里，然后自己处理窗口事件，这样还能支持最大化（