前言

这是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

已知问题