控制节点：
/sys/block/md127/md/sync_action
内核是怎么实现的，为什么mdadm管理命令仅支持四种？
[root@gitclient ~]# mdadm --action --help
mdadm: action must be one of idle, frozen, check, repair
内核文档是怎么描述这个节点？
sync_actiona text file that can be used to monitor and control the rebuildprocess. It contains one word which can be one of:resyncredundancy(冗余) is being recalculated after uncleanshutdown or creationrecovera hot spare is being built to replace afailed/missing deviceidlenothing is happeningcheckA full check of redundancy was requested and ishappening. This reads all blocks and checksthem. A repair may also happen for some raidlevels.repairA full check and repair is happening. This issimilar to ``resync``, but was requested by theuser, and the write-intent bitmap is NOT used tooptimise the process.This file is writable, and each of the strings that could beread are meaningful for writing.``idle`` will stop an active resync/recovery etc. There is noguarantee that another resync/recovery may not be automaticallystarted again, though some event will be needed to triggerthis.``resync`` or ``recovery`` can be used to restart thecorresponding operation if it was stopped with ``idle``.``check`` and ``repair`` will start the appropriate processproviding the current state is ``idle``.This file responds to select/poll. Any important change in the valuetriggers a poll event. Sometimes the value will briefly be``recover`` if a recovery seems to be needed, but cannot beachieved. In that case, the transition to ``recover`` isn'tnotified, but the transition away is.
如果单纯做check操作，怎么知道有哪些不同呢？
/sys/block/md127/md/mismatch_cnt
内核中对该字段的描述
mismatch_countWhen performing ``check`` and ``repair``, and possibly whenperforming ``resync``, md will count the number of errors that arefound. The count in ``mismatch_cnt`` is the number of sectorsthat were re-written, or (for ``check``) would have beenre-written. As most raid levels work in units of pages ratherthan sectors, this may be larger than the number of actual errorsby a factor of the number of sectors in a page.
在执行“检查”和“修复”，以及可能在执行“重新同步”时，md 将计算发现的错误数量。在“mismatch_cnt”中的计数是重新写入的扇区数量，或者（对于“检查”）本应该重新写入的扇区数量。由于大多数 RAID 级别以页面为单位工作，而不是以扇区为单位，因此这个数量可能会比实际错误数量大，大约是页面中扇区数量的倍数。
从上述描述来看，这个值也是不准确的？
-
向某块成员盘数据区写入数据，将raid阵列写坏。
[root@gitclient ~]# dd if=/dev/urandom of=/dev/sdb bs=512 count=1 seek=4096 oflag=direct 1+0 records in 1+0 records out 512 bytes copied, 0.0148909 s, 34.4 kB/s -
手动触发raid阵列检查操作。
[root@gitclient ~]# mdadm --action check /dev/md127 [root@gitclient ~]# cat /proc/mdstat Personalities : [raid1] md127 : active raid1 sdb[0] sdc[1]1046528 blocks super 1.2 [2/2] [UU][======>..............] check = 33.4% (350400/1046528) finish=0.0min speed=175200K/secbitmap: 0/1 pages [0KB], 65536KB chunkunused devices: <none> -
查看节点的值。
[root@gitclient ~]# cat /sys/block/md127/md/mismatch_cnt 128
为什么是128个扇区？
数据同步的默认单位是64K，也就是128个扇区，也就是说这个值记录的是某次IO操作尺寸。
到底内核是怎么给这个节点进行计数？这个值什么时候会被清理掉？
// md.c
// 定义文件节点。
static struct md_sysfs_entry md_mismatches = __ATTR_RO(mismatch_cnt);struct mddev {atomic64_t resync_mismatches; /* count of sectors where* parity/replica mismatch found*/
}// 节点show方法，读取的是mddev中元素的值。
static ssize_t
mismatch_cnt_show(struct mddev *mddev, char *page)
{return sprintf(page, "%llu\n",(unsigned long long)atomic64_read(&mddev->resync_mismatches));
}// process_checks函数会修改改字段的值。if (j >= 0)atomic64_add(r1_bio->sectors, &mddev->resync_mismatches);if (j < 0 || (test_bit(MD_RECOVERY_CHECK, &mddev->recovery)&& !status)) {/* No need to write to this device. */sbio->bi_end_io = NULL;rdev_dec_pending(conf->mirrors[i].rdev, mddev);continue;}
被清理掉的逻辑发生在md_clean和md_do_sync同步完成后再下check命令的场景下。
如何查看两个设备数据区存在差异呢？存在差异也不一定能够说明存在数据损坏？
sync; echo 3 > /proc/sys/vm/drop_caches
cmp -l /dev/sdb /dev/sdc
进行数据比较时记得清理掉缓存！！cmp有没有办法直接跳过缓存？
除了上述比较方法后也可以在内核驱动中添加打印来标识哪些数据不一致。
