文章目录
1. 前言
限于作者能力水平，本文可能存在谬误，因此而给读者带来的损失，作者不做任何承诺。
2. 案例背景
TI AM335x + Linux 4.19 内核，存储设备为 NAND FLASH，其包含 11 个分区，如下：
[ 1.635286] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[ 1.640473] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[ 1.648388] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[ 1.654908] nand: Micron MT29F2G08AAD
[ 1.658589] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 1.666252] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
[ 1.671692] 11 fixed-partitions partitions found on MTD device omap2-nand.0
[ 1.678704] Creating 11 MTD partitions on "omap2-nand.0":
[ 1.684146] 0x000000000000-0x000000020000 : "NAND.SPL"
[ 1.690415] 0x000000020000-0x000000040000 : "NAND.SPL.backup1"
[ 1.697268] 0x000000040000-0x000000060000 : "NAND.SPL.backup2"
[ 1.704018] 0x000000060000-0x000000080000 : "NAND.SPL.backup3"
[ 1.710719] 0x000000080000-0x0000000c0000 : "NAND.u-boot-spl-os"
[ 1.717798] 0x0000000c0000-0x0000001c0000 : "NAND.u-boot"
[ 1.724932] 0x0000001c0000-0x0000001e0000 : "NAND.u-boot-env"
[ 1.731558] 0x0000001e0000-0x000000200000 : "NAND.u-boot-env.backup1"
[ 1.738956] 0x000000200000-0x000000a00000 : "NAND.kernel"
[ 1.752614] 0x000000a00000-0x00000e000000 : "NAND.rootfs"
[ 1.958515] 0x00000e000000-0x000010000000 : "NAND.userdata"这 11 个分区，分别对应 Linux 下块设备节点 /dev/mtdblock[0~10] 。
3. 案例问题
在应用场景下，通过 dd 命令升级内核，即：
dd if=kernel.img of=/dev/mtdblock8通过上面的命令写入内核后，接着执行 reboot 命令重启系统。启动初期，U-Boot 读取内核并加载它。这样升级内核后，测试发现，某些次数的升级，内核无法启动。
4. 案例分析
要搞清楚故障的原因，需要回答下列 2 个问题：
1. dd 写 NAND 时，会不会使用 page cache ？
2. dd 写 NAND 时，对比 U-Boot 读 NAND，是否采用了相同的坏块策略 ？4.1 普通文件写入流程概要
文件系统 IO 栈 的工作过程，概要流程如下图：
用户发起读写操作时，并不是直接操作存储设备，而是需要经过较长的 IO 栈 才能完成数据的读写。读写操作大体上需依次经过虚拟文件系统 vfs、磁盘文件系统、block 层、设备驱动层，最后到达存储器件，器件处理完成后发送中断通知驱动程序。
来看一下 普通文件 经由 page cache 写入的概要流程(假定普通文件经由 ext4fs 管理，同时 open() 时没带 O_DIRECT, O_SYNC 标志位)，这里的代码流程将用来和后面通过 dd 操作 /dev/mtdblockN 设备的写入过程做对比。普通文件 经由 page cache 写入的概要流程代码如下：
// vfs
sys_write(fd, buf, count) /* fs/read_write.c */
vfs_write(f.file, buf, count, &pos);
// disk file system: ext4
ext4_file_write_iter() /* fs/ext4/file.c */
__generic_file_write_iter(iocb, from); /* mm/filemap.c */
generic_perform_write(file, from, iocb->ki_pos);
struct page *page;
...
// 首次，分配用于写入的 page cache 页面
a_ops->write_begin(file, mapping, pos, bytes, flags, &page, &fsdata);
ext4_write_begin() /* fs/ext4/inode.c */
...
/*
* 分配 或 寻找 一个符合条件的用于写入的 page cache 的页面。
* 首次，分配 page cache 页面。
*/
page = grab_cache_page_write_begin(mapping, index, flags);
...
__block_write_begin(page, pos, len, ext4_get_block);
...
*pagep = page; /* 返回 page cache 页面 */
...
/* 将数据从用户空间拷贝到内核空间 */
copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
...
/* 提交数据写入请求 */
a_ops->write_end(file, mapping, pos, bytes, copied, page, fsdata);
block_write_end(file, mapping, pos, len, copied, page, fsdata);
__block_commit_write(inode, page, start, start+copied); /* fs/buffer.c */从上面的代码流程可以看到，整个 write() 过程中，都没有涉及到任何存储设备相关的操作，这个实际的写入最终经由 submit_bio() 提交写入请求到存储设备，譬如 shrink_page_list() 回收 page cache 页面触发等。这些细节不是本文关注的重点，在此不再细表。
通过上面的代码分析，我们只需要了解到，文件一般情形下的写入过程会经过 page cache, write() 调用返回，并不意味着数据已经写入到存储设备。
4.2 dd 写 NAND 时，会不会使用 page cache ？
我们为什么要知道，dd 写入 NAND 时会不会经过 page cache ？因为如果经过 page cache，可能会因为 写入内容没有回写到 NAND ，而导致数据异常。
对 dd 不太熟悉的朋友，可能会误解，认为 dd 对块设备节点 /dev/mtdblockN 的操作，就是对存储设备的直接操作，不会经过 page cache，常常会误以为 page cache 仅用于普通文件操作。然而事实并非如此，后面的代码分析会揭示这一点。
接着从代码细节来看一看，dd 命令对块设备 /dev/mtdblockN 的写入过程，到底会不会经过 page cache ？这里只关注 dd if=kernel.img of=/dev/mtdblock8 命令的写操作，其读操作是否经过 page cache 和分析的问题无涉，故忽略。先看一下 open("/dev/mtdblock8") 的过程：
// 先看一下 open("/dev/mtdblock8") 的过程，主要关注 fops 和 a_ops 的绑定
open("/dev/mtdblock8")
...
vfs_open(&nd->path, file);
file->f_path = *path;
do_dentry_open(file, d_backing_inode(path->dentry), NULL);
...
f->f_op = fops_get(inode->i_fop); /* 绑定 fops: &def_blk_fops */
...
if (!open)
open = f->f_op->open; /* blkdev_open() */
if (open) {
open(inode, f) = blkdev_open(inode, f); /* fs/block_dev.c */
struct block_device *bdev;
...
bdev = bd_acquire(inode);
bdev = bdget(inode->i_rdev);
struct inode *inode;
inode = iget5_locked(blockdev_superblock, hash(dev),
bdev_test, bdev_set, &dev);
...
if (inode->i_state & I_NEW) {
...
inode->i_mode = S_IFBLK;
...
/* 绑定 address space 操作接口 */
inode->i_data.a_ops = &def_blk_aops;
...
}
...
...
return blkdev_get(bdev, filp->f_mode, filp);
}上面的流程，重点关注 f_op(struct file_operations) 绑定到了 def_blk_fops，而 a_ops(struct address_space_operations) 绑定到了 def_blk_aops 。dd 的写操作也没什么稀奇的，仍然是从 write() 发起：
// vfs
sys_write(fd, buf, count) /* fs/read_write.c */
vfs_write(f.file, buf, count, &pos);
...
blkdev_write_iter() /* fs/block_dev.c */
__generic_file_write_iter(iocb, from) /* mm/filemap.c */
/*
* 后面的写入流程，在没有指定 oflag=direct 的前提下，
* 和前面分析的 普通文件 的写入流程一样，都将会使用
* page cache !!!
*/
generic_perform_write(file, from, iocb->ki_pos);
struct page *page;
/* 首次，分配 page cache 页面 */
a_ops->write_begin(file, mapping, pos, bytes, flags, &page, &fsdata);
blkdev_write_begin()
block_write_begin(mapping, pos, len, flags, pagep, blkdev_get_block);
/*
* 分配 或 寻找 一个符合条件的用于写入的 page cache 的页面。
* 首次，分配 page cache 页面。
*/
page = grab_cache_page_write_begin(mapping, index, flags);
...
*pagep = page; /* 返回 page cache 页面 */
...
...
/* 将数据从用户空间拷贝到内核空间 */
copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
...
a_ops->write_end(file, mapping, pos, bytes, copied, page, fsdata);
blkdev_write_end()
...到此，我们可以给出本小节提出问题的答案。dd 写 NAND 时，会不会使用 page cache ？在 dd 命令未指定 oflag=direct 的前提下，dd 写入过程中的数据，会经过 page cache 。
4.3 dd 写 NAND 时，对比 U-Boot 读 NAND，是否采用了相同的坏块策略 ？
4.3.1 U-Boot 读 NAND 过程中遇坏块的处理策略
从博文 U-Boot: NAND 驱动简介 章节 3.3 NAND 写操作 和 3.4 NAND 读操作 分析知道，U-Boot 在 NAND 读写过程，遇到坏块会跳过，直到读取到要求数目的 block 为止，且坏块不会包含在读写 block 计数内。这就意味着，在 Linux 下通过 dd 写入 kernel.img ，也必须和 U-Boot 读操作保持相同的策略，即写入 NAND 时遇到坏块跳过，这样才使得启动期间 U-Boot 能正确读到 kernel.img 的完整内容，也才能正确加载内核。
4.3.2 Linux 写 NAND 过程中遇坏块的处理策略
首先，dd 并不对坏块做处理，这就要看 Linux 内核 NAND 驱动在读写过程中，对坏块的处理策略。这里只关注和本文相关写入过程中 NAND 驱动坏块处理过程。这里的分析，刻意跳过了前面冗长的无关部分，即前面分析提到的提交写操作请求到设备的部分(submit_bio())，我们重点关注块类设备拉取写操作请求，并进行实际对设备写入的部分。分析从 mtd_blktrans_work() 开始(Linux 将 NAND 设备抽象为 MTD 设备进行访问)：
// 在不影响主干逻辑的前提下，为方便查看，对代码有做一些改动。
mtd_blktrans_work() /* drivers/mtd/mtd_blkdevs.c */
// 拉取一个写入请求
req = blk_fetch_request(rq);
...
// 处理写入请求
do_blktrans_request(dev->tr, dev, req);
for (; nsect > 0; nsect--, block++, buf += tr->blksize) // (1)
tr->writesect(dev, block, buf) = mtdblock_writesect() /* drivers/mtd/mtdblock.c */
if (unlikely(!mtdblk->cache_data && mtdblk->cache_size)) {
/*
* 第一次写入, 分配 cache 缓存。
*
* 注意，这里的 cache 不同于 page cache，主要是为了一些
* 非对齐数据操作等。
*/
mtdblk->cache_data = vmalloc(mtdblk->mbd.mtd->erasesize);
}
do_cached_write(mtdblk, block<<9, 512, buf); /* drivers/mtd/mtdblock.c */
// 这里只取主干逻辑
...
while (len > 0) { // (2)
erase_write (mtd, pos, size, buf);
...
// 写入之前总是要先擦除
mtd_erase(mtd, &erase); /* drivers/mtd/mtdcore.c */
if (ret) { /* 擦除出错 */
...
// 打印擦除出错的范围区间
printk (KERN_WARNING "mtdblock: erase of region [0x%lx, 0x%x] "
"on \"%s\" failed\n",
pos, len, mtd->name);
return ret; // 擦除失败，终止写入过程
}
...
// 擦除成功后再写入
mtd_write(mtd, pos, len, &retlen, buf);
}
...
...
// 展开一下前面的 mtd_erase()
mtd_erase(mtd, &erase); /* drivers/mtd/mtdcore.c */
mtd->_erase(mtd, instr) = part_erase() /* drivers/mtd/mtdpart.c */
part->parent->_erase(part->parent, instr)
nand_erase() /* drivers/mtd/nand/nand_base.c */
nand_erase_nand(mtd, instr, 0)
...
instr->state = MTD_ERASING;
while (len) { // (3)
/* Check if we have a bad block, we do not erase bad blocks! */
// 检查擦除位置是不是有坏块：无法对坏块进行擦除操作
if (nand_block_checkbad(mtd, ((loff_t) page) <<
chip->page_shift, allowbbt)) {
// 打印擦除出错的 NAND PAGE 位置
pr_warn("%s: attempt to erase a bad block at page 0x%08x\n",
__func__, page);
instr->state = MTD_ERASE_FAILED; // 标记擦除出错
goto erase_exit; // 擦除出错，终止擦除过程
}
}
instr->state = MTD_ERASE_DONE;
erase_exit:
// 擦除正常完成为 MTD_ERASE_DONE 状态, 如果不是, 返回 EIO 错误码
ret = instr->state == MTD_ERASE_DONE ? 0 : -EIO;
...
return ret;上面的代码分析告诉我们，在 Linux 下，试图写入 NAND 坏块位置，NAND 驱动将会终止写入过程，并报告错误信息。如下是试图用 dd 写入坏块时的一个例子，内核爆出如下日志：
$ dd if=/mnt/nfs-remote/t.img bs=128K seek=416 count=8 of=/dev/mtdblock9 # 执行 dd 试图往坏块位置写入
[ 6002.927447] nand: nand_erase_nand: attempt to erase a bad block at page 0x00007c80
[ 6002.935145] mtdblock: erase of region [0x3440000, 0x20000] on "NAND.rootfs" failed
[ 6002.943396] print_req_error: I/O error, dev mtdblock9, sector 107264
[ 6002.949794] Buffer I/O error on dev mtdblock9, logical block 13408, lost async page write
[ 6002.958470] nand: nand_erase_nand: attempt to erase a bad block at page 0x00007c80
[ 6002.966143] mtdblock: erase of region [0x3440000, 0x20000] on "NAND.rootfs" failed
[ 6002.973973] print_req_error: I/O error, dev mtdblock9, sector 107272
[ 6002.980360] Buffer I/O error on dev mtdblock9, logical block 13409, lost async page write
......
[ 6003.231379] nand: nand_erase_nand: attempt to erase a bad block at page 0x00007c80
[ 6003.239003] mtdblock: erase of region [0x3440000, 0x20000] on "NAND.rootfs" failed
[ 6003.246899] nand: nand_erase_nand: attempt to erase a bad block at page 0x00007c80
[ 6003.254636] mtdblock: erase of region [0x3440000, 0x20000] on "NAND.rootfs" failed
......
8+0 records in
8+0 records out
# echo $? # 查询 dd 命令的执行退出码，惊不惊喜？意不意外？
0从上面 dd 测试写坏块的例子看到，即使往坏块位置去写，dd 的退出码依然是 0 ，这可能违反我们的直觉。从前面的代码分析可以知道，出现这种现象的根本原因是因为，写入 NAND 的操作实际上分为两步：write() 给出数据写入需求后返回；然后内核在某个不确定的时间点将写入请求提交给 NAND 设备，然后 NAND 设备驱动取出写入请求并做实际的写入操作。也就是说，写入的发起和实际写入，是一个异步过程，write() 返回成功并不表示写入成功，在 NAND 设备写入时如果出错，已经没法将这个错误返回给 write()，因为 write() 可能已经(成功)返回用户空间。
到此，仍然没有对 Linux 下 NAND 坏块管理策略做出说明。下面来分析说明这一点：
// 上面判断坏块的代码
nand_block_checkbad(mtd, ((loff_t) page) << chip->page_shift, allowbbt)) /* drivers/mtd/nand/nand_base.c */
struct nand_chip *chip = mtd_to_nand(mtd);
if (!chip->bbt) /* 没有在驱动加载初期, 扫描 NAND 建立位于内存 BBT 表的情形下, */
/*
* 用 NAND 的 OOB 区域 标记 判断 是不是 NAND 坏块.
* drivers/mtd/nand/nand_base.c, nand_block_bad()
* ...
*/
return chip->block_bad(mtd, ofs);
nand_block_bad()
...
for (; page < page_end; page++) {
/*
* 读取 NAND 不带 ECC 的 OOB 数据。
* drivers/mtd/nand/nand_base.c: nand_read_oob_std() [default]
* ...
*/
res = chip->ecc.read_oob(mtd, chip, page);
nand_read_oob_std()
// 从 NAND 设备读取 OOB
chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
...
bad = chip->oob_poi[chip->badblockpos];
/* 从 NAND 读取的 OOB 数据判定是否为坏块 */
if (likely(chip->badblockbits == 8))
res = bad != 0xFF;
else
res = hweight8(bad) < chip->badblockbits;
if (res)
return res; /* 坏块 */
}
return 0; /* 非坏块 */
/* Return info from the table */
return nand_isbad_bbt(mtd, ofs, allowbbt); /* 从已经建立的内存 BBT 表判定是否为坏块 */从上面的代码分析知道，在 U-Boot 读时、Linux 写时遇到坏块的处理策略上存在差异：U-Boot 读时会跳过坏块，直到读取到要求的大小为止；而 Linux 写时，遇到坏块会报错并终止对 NAND 设备的写入过程，但由于实际对 NAND 设备的写操作相对 write() 调用是异步的，而不是在 write() 调用中完成，因此实际写操作过程中的错误状况无法反馈给 write()，即 dd 的 write() 的调用在写坏块时不会返回错误码，导致即使实际的 NAND 设备写操作发生了错误，dd 仍会继续完成所有的写操作，并最终以错误码 0 成功退出。
5. 解决方案
针对本文讨论的 2 个问题：
1. dd 写 NAND 时，会不会使用 page cache ？
2. dd 写 NAND 时，对比 U-Boot 读 NAND，是否采用了相同的坏块策略 ？分别对它们给出解决方案。
5.1 避免数据在 page cache 逗留
对于问题 1. ，可以通过将 dd 命令行选项 oflag=direct 来解决，这样写入数据可以绕过 page cache 。来看看代码实现细节：
/*
* coreutils 的 dd 命令将 oflag=direct 转换为 O_DIRECT
*/
/* src/dd.c */
/* Flags, for iflag="..." and oflag="...". */
static struct symbol_value const flags[] =
{
...
{"direct", O_DIRECT},
...
{"", 0}
};/*
* write() 时，如果设置了 O_DIRECT 的处理流程
*/
static inline bool io_is_direct(struct file *filp)
{
return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
}
static inline int iocb_flags(struct file *file)
{
int res = 0;
...
if (io_is_direct(file))
res |= IOCB_DIRECT; // O_DIRECT ==> IOCB_DIRECT
...
return res;
}
// vfs
sys_write(fd, buf, count) /* fs/read_write.c */
vfs_write(f.file, buf, count, &pos);
// 这里比前面的分析细化了一点，主要是标志位 O_DIRECT 的处理
__vfs_write(file, buf, count, pos);
new_sync_write(file, p, count, pos);
...
init_sync_kiocb(&kiocb, filp);
*kiocb = (struct kiocb) {
...
.ki_flags = iocb_flags(filp), // O_DIRECT ==> IOCB_DIRECT
...
};
...
call_write_iter(filp, &kiocb, &iter);
blkdev_write_iter()
__generic_file_write_iter(iocb, from);
...
if (iocb->ki_flags & IOCB_DIRECT) { /* O_DIRECT */
loff_t pos, endbyte;
/* 不通过 page cache 的 direct IO */
written = generic_file_direct_write(iocb, from);
/*
* If the write stopped short of completing, fall back to
* buffered writes. Some filesystems do this for writes to
* holes, for example. For DAX files, a buffered write will
* not succeed (even if it did, DAX does not handle dirty
* page-cache pages correctly).
*/
if (written < 0 || !iov_iter_count(from) || IS_DAX(inode))
goto out;
/*
* 如果不带 page cache 的 direct 没有写入所有数据 或 失败，
* 我们用带 page cache 的 写入操作，此时，为了保持 O_DIRECT
* 的语义，需要将 page cache 中写入的内容刷入到存储设备，然
* 后将这些 page cache 页面置为无效状态。
*/
status = generic_perform_write(file, from, pos = iocb->ki_pos);
...
endbyte = pos + status - 1;
err = filemap_write_and_wait_range(mapping, pos, endbyte);
if (err == 0) {
iocb->ki_pos = endbyte + 1;
written += status;
/* 将 page cache 页面置为无效状态 */
invalidate_mapping_pages(mapping,
pos >> PAGE_SHIFT,
endbyte >> PAGE_SHIFT);
} else {
...
}
} else {
// 没有设置 O_DIRECT 的时候执行路径，也就是前面分析的执行路径
...
}
// 展开 generic_file_direct_write()
written = generic_file_direct_write(iocb, from); /* 不通过 page cache 的 direct IO */
...
// 这里代码有做些调整，不影响主干逻辑
written = filemap_write_and_wait_range(mapping, pos, pos + write_len - 1);
...
written = invalidate_inode_pages2_range(mapping, pos >> PAGE_SHIFT, end);
...
written = mapping->a_ops->direct_IO(iocb, from);
blkdev_direct_IO(iocb, from)
__blkdev_direct_IO(iocb, iter, min(nr_pages, BIO_MAX_PAGES));
...
/* 分配当前数据的第一个 bio */
bio = bio_alloc_bioset(GFP_KERNEL, nr_pages, blkdev_dio_pool);
bio_get(bio); /* extra ref for the completion handler */
...
dio->is_sync = is_sync = is_sync_kiocb(iocb);
if (dio->is_sync)
dio->waiter = current;
else
...
...
for (;;) {
bio_set_dev(bio, bdev);
bio->bi_iter.bi_sector = pos >> 9;
...
/* 设置 bio 已经提交到 io 请求队列时回调, 但数据还没有写到存储设备 */
bio->bi_end_io = blkdev_bio_end_io;
...
nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
if (!nr_pages) {
qc = submit_bio(bio); /* 提交当前数据的最后一个 bio 请求 */
break; /* 退出循环 */
}
...
submit_bio(bio); /* 提交一个 bio 请求 */
bio = bio_alloc(GFP_KERNEL, nr_pages); /* 分配一个新的 bio */
}
...
/* 等待所有 bio 进入 io 请求队列 */
for (;;) {
// bio 进入 io 请求队列时触发的回调 blkdev_bio_end_io()
// 修改 dio->waiter 并唤醒在这里等待的进程。
set_current_state(TASK_UNINTERRUPTIBLE);
if (!READ_ONCE(dio->waiter))
break;
if (!(iocb->ki_flags & IOCB_HIPRI) ||
!blk_mq_poll(bdev_get_queue(bdev), qc))
io_schedule();
}
__set_current_state(TASK_RUNNING);
...
...
iov_iter_revert(from, write_len - iov_iter_count(from));
out:
return written; // 返回 direct IO 写入字节数
blkdev_bio_end_io()
if (dio->multi_bio && !atomic_dec_and_test(&dio->ref)) {
...
} else {
if (!dio->is_sync) {
...
} else {
struct task_struct *waiter = dio->waiter;
/*
* 唤醒在 __blkdev_direct_IO() 等待 bio 进入 io 请求队列的进程：
* __blkdev_direct_IO()
* for (;;) {
* set_current_state(TASK_UNINTERRUPTIBLE);
* if (!READ_ONCE(dio->waiter))
* break;
* ...
* }
*/
WRITE_ONCE(dio->waiter, NULL);
wake_up_process(waiter);
}
}
...从上面的分析我们了解到，dd 带上 oflag=direct (即 open() 带上 O_DIRECT 标志)，告诉内核不使用 page cache(或同等操作，详见代码分析)进行写入操作，这样可以避免数据逗留在 page cache 而导致数据异常的情况。但要知道的是，write() 调用返回时，只是保证写入的 bio 已经进行设备的 io 请求队列；至于这些 io 请求什么时候兑现，即真正的将数据写入存储设备，这是不确定的，write() 仍然无法知道存储设备的写入错误。
前面提到了 bio，有必要对 bio 做一些简单说明。按照 io 请求的生命周期，io 请求被抽象成了 bio、request(简称 rq)、cmd。bio 由前面提到的 submit_bio() 接口提交。访问存储器件上相邻区域的 bio、request 可能会被合并，称为 bio merge、request merge。若 bio 的长度超过软件或者硬件的限制，bio 会被拆分成多个，称为 bio split。block 层接收到一个 bio 后，这个 bio 将生成一个新的 request，或者合并到已有的 request 中。如下图所示：
更多关于 bio 的细节，可参考博文 linux IO Block layer 解析 。
5.2 数据写入同步
章节 5.1 中，给 dd 加上 oflag=direct 避免了写入数据在 page cache 逗留的问题。如果同时给 dd 带上 oflag=sync 标记(即 dd oflag=direct,sync) ，则可以认为在没有写入错误的情况下(没遇到坏块)， write() 调用返回时数据已经写入设备(实际上这也只是软件层面的保证，存储设备本身可能也会有写入缓存)。来看一下 dd 带上 oflag=sync 标记时发生了什么。首先 dd 将 oflag=sync 转换为 O_SYNC 标记：
/* src/dd.c */
/* Flags, for iflag="..." and oflag="...". */
static struct symbol_value const flags[] =
{
...
{"sync", O_SYNC},
...
{"", 0}
};看 O_SYNC 标记对写入过程的影响：
/*
* write() 时，如果设置了 O_SYNC 的处理流程
*/
#ifndef O_SYNC
#define __O_SYNC 04000000
#define O_SYNC (__O_SYNC|O_DSYNC)
#endif
static inline int iocb_flags(struct file *file)
{
int res = 0;
...
// O_SYNC ==> IOCB_DSYNC | IOCB_SYNC
if ((file->f_flags & O_DSYNC) || IS_SYNC(file->f_mapping->host))
res |= IOCB_DSYNC;
if (file->f_flags & __O_SYNC)
res |= IOCB_SYNC;
return res;
}
// vfs
sys_write(fd, buf, count) /* fs/read_write.c */
vfs_write(f.file, buf, count, &pos);
__vfs_write(file, buf, count, pos);
new_sync_write(file, p, count, pos);
init_sync_kiocb(&kiocb, filp);
*kiocb = (struct kiocb) {
...
// O_SYNC ==> IOCB_DSYNC | IOCB_SYNC
.ki_flags = iocb_flags(filp),
...
};
call_write_iter(filp, &kiocb, &iter);
blkdev_write_iter()
ret = __generic_file_write_iter(iocb, from);
if (ret > 0) /* 写入成功, 根据 sync 设置看是否要做数据同步操作 */
ret = generic_write_sync(iocb, ret);
if (iocb->ki_flags & IOCB_DSYNC) { /* 如果需要做数据同步操作 */
/* 做数据同步操作 */
int ret = vfs_fsync_range(iocb->ki_filp,
iocb->ki_pos - count, iocb->ki_pos - 1,
(iocb->ki_flags & IOCB_SYNC) ? 0 : 1);
if (ret) /* 数据同步操作出错 */
return ret;
}
return count; /* 数据同步操作成功 */
...
// 展开一下 vfs_fsync_range()
int ret = vfs_fsync_range(iocb->ki_filp,
iocb->ki_pos - count, iocb->ki_pos - 1,
(iocb->ki_flags & IOCB_SYNC) ? 0 : 1);
...
return file->f_op->fsync(file, start, end, datasync);
blkdev_fsync(file, start, end, datasync)
error = file_write_and_wait_range(filp, start, end);
...
error = blkdev_issue_flush(bdev, GFP_KERNEL, NULL);
...
bio = bio_alloc(gfp_mask, 0);
bio_set_dev(bio, bdev);
bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH; // flush 数据到存储设备
ret = submit_bio_wait(bio);
...5.3 将 Linux 内核写入坏块处理 和 U-Boot 保持一直：跳过坏快
从前面分析了解到，直接使用 dd ，无法自动跳过坏块，那么就需要通过 MTD 子系统提供的字符类设备 /dev/mtdN 来进行编程：
1. 通过 ioctl(MEMGETBADBLOCK) 判定设备的坏块，写入遇到坏块时跳过；
2. 写数据时进行数据同步，从软件层面确保写入操作完成时，数据已经到达存储设备。到此，对于本文所叙问题，已经给出了一个解决方案，这不一定是唯一或者最好的解决方案，甚至在实际场景都不一定是正确的解决方案，一切都需要时间来验证。要注意的是，sync 和 direct IO 都可能导致性能损失，这需要权衡是否能够用在实际环境中。
6. 参考资料
[1] linux IO Block layer 解析
[2] https://www.man7.org/linux/man-pages/man1/dd.1.html
