这就是为啥红帽系统升级会弄重启升级了

其实 v8 的很多数组方法都是 js 写的 - 只是标记成 native ，毕竟无论如何都要做各种类型检查和转换（以及按 es 语义调用 proxy getter setter ），加上 es 语义允许数组方法在非数组类型上调用，native 写不会有多少优势 - 反而可能会漏掉一些语义保证）

按标准 get 还能带 body 呢（虽然浏览器不支持以防止恶意使用攻击实现不正确的服务端）
所以这事主要还得看自己定义的上层语义

只是服务器合并了一个 ACK 和 FIN 而已，教科书级别的 tcp 是允许一边关闭然后另一边继续发的，但是对于 http 服务器来说客户端关闭上行通道，同时响应已经发送完毕的情况下，没有必要继续保留连接了

@abcbuzhiming console.log 不是实时评估的，log 当时没有的话就没了（但是点击展开按钮时又是实时的了

Microsoft Print to PDF 这个走的是打印接口，拿到的就已经是图像本身了，另存 pdf 是浏览器自行实现的

首先解析不完整的源码，并能忽略部分语法错误这件事就很难了（正常编译器遇到语法错误就直接停下了，你还得强行继续解析直到拿到所有需要的信息）
其次不完整甚至有错误的语法解析了之后还要做语义分析（比方说类型），又是半个编译器前端，分析了之后根据类型提示，又得需要周围上下文信息
如果有多个文件还需要递归扫描依赖文件，于是可能还需要项目配置的信息
除此之外你还得考虑文件很多也很大，不能每次用户按键都全量扫描，得增量
这些做完了，再来考虑上下文提示
最好祈祷语言不要有元编程，不然还得在分析器里跑用户代码，用户写了个死循环，啪，你死了（而且有些死循环只是用户还没写完代码的中间状态才有的）
纯替换的宏的话稍微简单一点，但只有一点点，如何在宏中间补全又是一个史诗级难题

这种比较适合用 ebpf 做统计）

@pagxir 常见的是用 pv ，它的 buffer 是实打实的（和前面说的 buffer 命令类似机制），还能顺带显示进度条

@pagxir 模拟瓶颈在 io 也很好模拟，qemu 贴心的提供了限制 io 速度的方法，用 throttling.bps-total 限制就可以
限速到 10MB 的时候
/ # time sh -c 'dd if=/dev/sda bs=2M | gzip > /dev/null'
8+0 records in
8+0 records out
16777216 bytes (16.0MB) copied, 1.579849 seconds, 10.1MB/s
real 0m 1.59s
user 0m 0.92s
sys 0m 0.27s
/ # time sh -c 'gzip -c /dev/sda > /dev/null'
real 0m 1.53s
user 0m 0.97s
sys 0m 0.11s
作为对比，如果管道前面是 cat
/ # time sh -c 'cat /dev/sda | gzip > /dev/null'
real 0m 1.53s
user 0m 0.88s
sys 0m 0.24s
具体用时可能略有浮动（ gzip 这边就很稳定在 1.53 ，dd 组有时候有异常数据到两秒以上），但是差距还是在这的
dd 的问题是：write 它也会阻塞，阻塞了之后 read 自然也不会被调用，压缩用的 cpu 太少了，以至于 io 是瓶颈的时候性能并没有啥太大区别）
关于 dd 作为缓冲的作用，有好多文章写了这个问题
https://unix.stackexchange.com/questions/345072/can-dd-be-used-to-add-a-buffer-to-a-pipe
https://unix.stackexchange.com/questions/21918/utility-to-buffer-an-unbounded-amount-of-data-in-a-pipeline

@pagxir 如果你想达到所谓的缓冲效果，dd 是没有的，有个第三方软件 https://linux.die.net/man/1/buffer 可以实现你想要的结果，它内部实现了一个环形缓冲区，然后可以实现所谓的一边读取，一边写入——但是实际测试可以发现，它的效果比想象中的差很多，内核提供的 128k 的预读已经可以完成足够多的加速，如上所述，gzip 请求大小是 64k ，所以本来就可以在压缩的过程中请求 io

@pagxir 加两个不是更慢？？？
dd 也没开啥边读边写的操作啊，从上面 strace 的结果也可以看到，只是单纯的 read 固定长度然后 write ，这些全都是阻塞操作，没有使用 aio/io_uring ，多线程读写等的操作（源代码里也没有引用线程有关的东西），而 linux pipe 的默认缓冲区只有 64kb ，也就是读取端没有读完的话，写入端写入最多 64k 就会阻塞，即便你把缓冲区选择较小的范围，那也只是凭空增加系统调用数量，因为 gzip 仍然是一次性请求至少 64k （来自源代码，或者你也可以自己 strace 查看），因此 dd 开的越多只会越慢，不知道你怎么弄出“缓冲预读”的功能的
开 kvm 会让数据波动范围变大，除此之外不能改变结论，我特意选择小文件以缩小差距

js 的最大缺陷大概就是没有（支持直接共享内存的）原生线程吧，worker 的线程其实也可以用一些同步原语（包括原子操作和锁定语义），SharedArrayBuffer 也不是没有——但是只能操作二进制数据，不能直接用来传递对象——因而进行相关封装的就比较少（所谓阻塞队列，基本也是在多线程语境下才有意义吧），这也是为什么明明 wasm 性能不一定比 js 好，但是仍然有很多用到多线程处理的库采用 wasm 进行（
不过对于简单的多线程处理，采用 postMessage 的方法也不是完全不能接受，太重的计算就不太适合了

不是支持不支持的问题，是格式已经不能改了，cron 语法设计毫无扩展性，字段加哪里都不行
* * * * * 后面跟命令行
请问你秒打算加哪里？
这显然不能随便动啊，楼上不是说了有 systemd 的 timer ，完全换一个格式就没有 cron 上打补丁的问题

@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 跟踪的时候消失，然后做你所说的那些操作吧）