前言
这是part1，part2是更换硬盘，懒得写了改天更新
不是新手向的，不是新手向的，不是新手向的
mdadm挺稳定的，mdadmin挺稳定的，mdadm挺稳定的
fnOS的文件系统嵌套的层数有点过分，用着一直不是很痛快，他的文件系统是这样套娃的：
/dev/sdX -> mdadm(raid) -> lvm -> btrfs
由于fnOS的盘换了系统能直接识别，所以一定会在一些地方留下标记，比较显然的就是vgname的格式：trim_{uuid}，用fapolicyd记录一下trim是怎么创建存储空间的
吐槽一下自己，好像没拿fapolicy来做过audit，全用来分析软件行为了
可以看到过程中除了vgname=trim_{uuid} lvname=0外，trim进程没有留下别的tag
大胆推测小心取证，只要我们的vgname和lvname符合上述规律，飞牛就可以在/dev/mapper里识别到trime_{uuid}-0，只要trim支持这个lv最后做成的格式，就可以使用了
已经帮大家试过了，结论就是目前只支持ext4和btrfs，前端有报错，就懒得用fapolicyd看了， 应该是写死在trim的二进制程序里的，fapolicyd也看不到啥
所以按理来说，xfs的支持真的有手就行，只差一个挂载了，不知道飞牛团队什么时候能安排一下
操作步骤
pvcreate
pvcreate /dev/sdX
vgcreate
uuidgen |awk '{gsub("-","_",$1); print "trim_"$1}
vgcreate trim_{uuid} /dev/sdX
lvcreate
lvcreate -l +100%FREE -n 0 -y trim_{uuid}/dev/sdX
mkfs.btrfs
mkfs.btrfs \
-d raid0 \
-m raid1 \
/dev/trim_77613c80_e0c3_4e95_8f6e_114ae5b7330d/0 \
/dev/trim_77613c80_e0c3_4e95_8f6e_114ae5b7330d/1 \
/dev/trim_77613c80_e0c3_4e95_8f6e_114ae5b7330d/2
尝试挂载
另外两个盘会提示未挂载
重启看看有没有问题
升级看看有没有问题
good
因为没有套一层mdadm，可以直接当条带用了，对于重要文件可以做多副本或raid5
btrfs subvolume create /vol1/1000/data
btrfs property set /vol1/1000/data disk_space raid5
已知问题
