- 主题:我也真是服了做lvm这帮人了，史上最坑
lvm的raid是基于linux md raid。
如果你拿几个空白盘新建一个raid5或raid6.
Linux md raid的文档中写：raid 6可以skip initial sync, raid 5不能。
到了LVM这边，成了反过来：raid 5可以skip initial sync, raid 6不能。而且文档还写的有模有样头头是道。不信你去看看，写的特别有道理。
实际我测了一下：
1. 先组一个raid 5
2. 然后写入一个文件，并计算md5。把md5结果存在额外别的硬盘上。
3. 然后拔掉一个盘，重启。尝试读取原来的文件，并计算md5，没有问题。
然后，高潮来了。当我把丢失的盘加回来之后，数据全没了。
dmesg显示：
[ 84.372238] EXT4-fs (dm-12): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[ 88.627275] EXT4-fs error (device dm-12): ext4_validate_block_bitmap:390: comm rm: bg 37: bad block bitmap checksum
[ 88.629128] EXT4-fs error (device dm-12) in ext4_free_blocks:6109: Filesystem failed CRC
[ 89.149337] EXT4-fs error (device dm-12): ext4_validate_block_bitmap:390: comm rm: bg 36: bad block bitmap checksum
[ 89.151233] EXT4-fs error (device dm-12) in ext4_free_blocks:6109: Filesystem failed CRC
[ 89.713979] EXT4-fs error (device dm-12): ext4_validate_block_bitmap:390: comm rm: bg 35: bad block bitmap checksum
[ 89.715873] EXT4-fs error (device dm-12) in ext4_free_blocks:6109: Filesystem failed CRC
[ 90.226810] EXT4-fs error (device dm-12): ext4_validate_block_bitmap:390: comm rm: bg 34: bad block bitmap checksum
[ 90.228705] EXT4-fs error (device dm-12) in ext4_free_blocks:6109: Filesystem failed CRC
[ 90.733677] EXT4-fs error (device dm-12): ext4_validate_block_bitmap:390: comm rm: bg 33: bad block bitmap checksum
[ 90.735654] EXT4-fs error (device dm-12) in ext4_free_blocks:6109: Filesystem failed CRC
我猜测可能是它用错误的parity bit去做恢复了。
至于为什么我要skip initial sync: 我6个8TB的硬盘你猜它要花多久sync？ 20天！ 我吃了饭回来，一个小时sync了0.2%。为什么？因为我启用了integrity check。integrity这个feature需要把整个硬盘先读写一遍，一般来说大约是200MB/s的速度，还可。应该是这个昨晚之后再开始组raid。但是LVM不管啊，两个操作一起搞。好好的顺序读写变成了4k大小的随机读写。而机械硬盘的4k随机读写的性能就跟屎一样。
--
FROM 107.139.34.*
我读书太少，还以为mdadm专做raid，lvm专做volume manager，这俩分层用就行，没想到还有lvm raid
--
FROM 43.224.44.*
擦，我也是这么认为的，一直没用过lvm
【 在 KeepHope (Walk towards the better future) 的大作中提到: 】
: 我读书太少，还以为mdadm专做raid，lvm专做volume manager，这俩分层用就行，没想到还有lvm raid
--
FROM 114.86.225.*
mdadm和lvm我都用，尤其lvm用的最多，因为云主机经常需要动态扩容
也在md上层用过lvm，当然更多的时候是硬RAID上lvm，比如LSI
但lvm raid这个一体化的概念确实第一次听说
【 在 RuralHunter 的大作中提到: 】
: 擦，我也是这么认为的，一直没用过lvm
:
--
FROM 43.224.44.*
lvm 做 raid 是后来加入的功能，用的是 mdadm 的
还可以做 cache，害我丢了数据。垃圾啊。
后来我就用 mdadm + btrfs，大不了把 btrfs 的 nocow 打开。不用 lvm 这种垃圾。
【 在 KeepHope (Walk towards the better future) 的大作中提到: 】
: 我读书太少，还以为mdadm专做raid，lvm专做volume manager，这俩分层用就行，没想到还有lvm raid
--
修改:hgoldfish FROM 110.81.14.*
FROM 110.81.14.*
这么高级的用法啊，btrfs不是自己就可以吗
【 在 hgoldfish (老鱼) 的大作中提到: 】
: lvm 做 raid 是后来加入的功能，用的是 mdadm 的
: 还可以做 cache，害我丢了数据。垃圾啊。
: 后来我就用 mdadm + btrfs，大不了把 btrfs 的 nocow 打开。不用 lvm 这种垃圾。
--
FROM 106.37.96.*
说错说错。。我现在就只用 btrfs 了。
【 在 cppbuilder (心如止水~) 的大作中提到: 】
: 这么高级的用法啊，btrfs不是自己就可以吗
--
FROM 110.81.14.*
【 在 hgoldfish 的大作中提到: 】
: lvm 做 raid 是后来加入的功能，用的是 mdadm 的
所以这是最搞笑的啊。明明底层就是mdadm。但是功能上到它这却反了过来。
--
FROM 107.139.34.*
【 在 hgoldfish 的大作中提到: 】
: 还可以做 cache，害我丢了数据。垃圾啊。
是为什么丢数据？你用是lvm的cache还是writecache?
--
FROM 107.139.34.*
确实，贴近底层的部分做太高级的抽象并不是好事，简单条带式存储的话直接btrfs挺好的。
需要raid的场景下，用btrfs自带的raid功能也比md可靠，性能损耗忽略不计吧，毕竟都用hdd和btrfs了。如果真极端在意性能就老老实实md+ext4
【 在 hgoldfish 的大作中提到: 】
: lvm 做 raid 是后来加入的功能，用的是 mdadm 的
: 还可以做 cache，害我丢了数据。垃圾啊。
: 后来我就用 mdadm + btrfs，大不了把 btrfs 的 nocow 打开。不用 lvm 这种垃圾。
: ...................
--
FROM 49.7.47.*