咱们来一步步拆解你的问题：

一、你给出的dd命令不会触发SD卡的Sequential-command（顺序命令） #

你用的命令是先挂载SD卡分区到/mnt，再通过dd写入文件系统上的文件：

~# mount /dev/mmcblk0p1 /mnt 
~# time sh -c "dd if=/dev/zero of=/mnt/file bs=4k count=200000 && sync"

这种方式下，你的写入请求会经过文件系统抽象层（比如ext4、FAT32这类）、虚拟文件系统（VFS），最后才到SD卡驱动。文件系统会把连续写入请求拆分成符合自身块大小的操作，再加上元数据更新（比如inode、目录项），SD卡驱动收到的是零散的块请求，不会触发连续数据流的Sequential-command，而是用Block-oriented-command（块导向命令）处理每个带CRC校验的块。

二、实现SD卡流数据写入的替代方法 #

要触发SD卡的Sequential-command，你需要绕过文件系统，直接向裸设备写入连续数据，这样SD卡驱动能识别到连续的大尺寸请求，启动连续数据流传输。

具体命令示例（注意：此操作会直接覆盖SD卡上的所有数据，务必提前备份重要内容，且确认设备路径正确！）：

~# time sh -c "dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=200 && sync"

这里直接写入/dev/mmcblk0（SD卡的裸设备节点，而非分区），用较大的块大小（比如1M），驱动会将连续请求合并成连续数据流，触发SD卡的Sequential-command，从而实现流数据写入的基准测试。

三、用dd执行块导向命令的读写操作 #

块导向命令是SD卡的默认常规操作，以下两种场景都能实现：

1. 挂载文件系统后读写文件：就像你最开始的命令，文件系统会自动将数据拆分成带CRC校验的块，通过Block-oriented-command发送给SD卡，适合日常文件读写测试。
2. 直接读写裸设备的小尺寸块：指定SD卡的标准块大小（通常是512字节或4K，取决于SD卡规格），每个块都会单独发送并校验CRC，示例命令：
   • 读操作：

     dd if=/dev/mmcblk0p1 of=/tmp/test_block.img bs=512 count=1000
     

   • 写操作：

     dd if=/tmp/test_block.img of=/dev/mmcblk0p1 bs=512 count=1000
     

这种方式下，每个bs指定的块都是单独的Block-oriented-command请求，带CRC校验，适合测试SD卡的随机块读写性能。

内容的提问来源于stack exchange，提问作者Thale