在OpenMediaVault里干掉RAID5，升级RAID6

其实mdadm支持直接把raid5升级为raid6的……

话说，R6一样有Write Hole，不知道现在文件系统的journal和journal checksum机制是否能够去除这种问题

xudaiqing 发表于 2015-11-6 09:27
32K＊8 怎么会不够，这是内存，不是flash。而且并不要去记录每一次写入的实际数据，只需要记录对应的地址 ...

文件系统应当保证块设备正常工作时不会丢数据
块设备本身应当保证确认写入之后的每次对同一LBA的读取都应当返回相同的结果

我们习惯于假设写入是一个全提交或者全撤销的操作，也就是每次读取，要么是刚写入的，要么是之前的
Write Hole破坏了这一假设，会导致读出来的不是刚写入的，也不是之前的，这对文件系统来说是完全不期望的

xudaiqing 发表于 2015-11-6 11:43
显然不是这样的，日志文件系统和写时复制就是用来应对瞬间断电时当前在写入的块的状态是不确定的现实。日 ...

Write hole 的问题是，在某些实现中，下层块设备返回写完成的时候，校验盘实际上没有完成
而文件系统假设这一笔已经提交
在此时断电后，如果没有NVRAM之类的方式来将校验盘进行同步，那么校验盘的数据就永远不同步了
特别是R5，每次部分写都是只更新校验盘的，除非通过数据巡检来检查

而且对于用户数据，data=ordered这个最常用的选项根本没法对数据进行保护

文件系统应当做到的，事实上不一定会做到，甚至很多人放弃这一点换取性能
我之前试过，data=journal会导致写入性能只有几M，基本不能忍了

nighttob 发表于 2015-11-6 18:12
对RAID来说，XOR是RAID逻辑算出来的，下面的块设备仍然是LBA读、写操作。（话说这还是我第一次在论坛看见有 ...

也是
我现在对于自认为比较重要的数据，移动的时候都得校验的

mdadm最近在做相关的东西，不知道会咋样
https://lkml.org/lkml/2015/11/1/232

现在的趋势好像有逐步打破块设备、文件系统、缓存之间的壁垒的趋势
mdadm要开始搞ssd cache了
btrfs和zfs要搞raid了
不过增加的复杂度，又更容易导致bug了……

话说，楼主能登陆一下ssh，看一下 /sys/block/md0/md/stripe_cache_size 的值是多少么

overthink 发表于 2015-11-7 19:14
8192

我这里是256，难怪很慢……
改成8192就能到近百了

overthink 发表于 2015-11-8 08:24
NAS应用建议stripe size大一些。

这个的修改直接改配置文件就可以了吧？

stripe size是chunk size吧？这个在创建raid的时候就确定了
我说的那个是缓存

nighttob 发表于 2015-11-9 15:10
你觉得咱们说RAID里“条带”这个词是指Strip还是Stripe?

按照定义，Strip Size和Stripe Size是两个概念 ...

我错了，作为mdadm使用者，我用了从没定义过的用语

https://raid.wiki.kernel.org/index.php/RAID_setup

With a raid using a chunk size of 4k (also called stride-size). With two disks, the #disk * stride-size product (also called stripe-width) is 2*4k=8k

实际上从来没注意过stripe/strip/stride的区别，自己一直用size和width来区分的