最近在用 dd 命令当作 16 进制编辑器来组装文件
用法类似于
dd status=none if=/dev/zero bs=1048576 count=${size} | tr '\000' '\377' > ${tmpfile}
先生成指定大小${size}的一个文件并用 0xFF 填充
分别写入几个小文件
dd status=none conv=notrunc if=${art} of=${tmpfile} seek=${artoffset} bs=1
dd status=none conv=notrunc if=${uboot} of=${tmpfile} seek=0 bs=1
dd status=none conv=notrunc if=${firmware} of=${tmpfile} seek=${ubootsize} bs=1
(估计有人看出来了,其实就是用来做编程器镜像的:P )
这个肯定是没问题的,但是在写入${firmware}的时候,会发现效率很低,因为 bs=1 嘛
于是我尝试修改了一下 bs ,结果带来 2 个问题
1 、因为一开始没意识到 seek 和 bs 的关系——按照 man 说明, seek 其实是 blocks ,也就是 seek * bs 才是最终 offset ,结果生成了一个超大的文件( 1.7TB ),这已经远远超出了我磁盘的空间,但是删除后没发现有什么文件被覆盖,为什么呢?是因为其实前面都被 seek 掉了么,其实写入的还是${firmware}流的大小?
2 、既然 seek 和 bs 紧密相关,有没有提高 I/O 效率的方式呢?
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.