前情提要
首先，我说一下我的飞牛os运行平台:软件方面:win10 22H2，Hyper-V，VHDX动态调整。硬件方面:笔记本，一个固态，一个1T 、一个2T 机械硬盘。飞牛os系统安装在固态，两个存储空间分别为900G、1.8T，储存在两个机械里。
之前安装飞牛的时候出于半测试半试用的心态，对于数据盘的分配有点随意。随着逐渐的折腾，安装了不少几个Docker和一些个人文件在存储空间1上，也就是那个1T的机械硬盘。因为是CMR，Docker安装运行也还能接受。后来感觉折腾的差不多了也就开着机放在一边。
就在这个月，心血来潮就把1T机械换成5T机械，过程同样坎坷，有感兴趣的再单独开一贴，这次就不详细说了。当我把1T的VHDX文件移动到5T里时，问题慢慢出现了。
开机以后的几分钟内那个硬盘指示灯就跟打了**血似的，进任务管理器里查看那个5T的硬盘使用率基本上是100，响应时间动不动就是一千多毫秒，但是读写速度也就几M每秒。飞牛里的症状就是Docker服务要很长时间才能起来，安装系统应用也是慢的不行。结合硬盘状态，原因也就浮出水面了，就是单纯的机械硬盘的4k随机读写太拉胯，而Docker和飞牛系统应用大部分都是小文件。这也回答了我心中另一个困惑，刚开机的时候1panel无法访问。
找到了原因，下一步就是寻找解决的方法。第一个把Docker安装在固态里。太麻烦，pass。第二个就是对VHDX下手。在网上搜了搜，发现最方便的就是把动态调整改为固定大小。想着既然要折腾，索性就把存储空间1调小，专门用于存放docker和应用。
第一次折腾开始
从网上搜索可知，gparted可以图形化调整分区，支持btrfs（存储空间1创建的时候是btrfs分区）。下载LiveCD，创建虚拟机，同时挂载存储空间1的VHDX虚拟磁盘。重启好几遍也无法进入图形界面，最后发现只能以低分辨率低色彩进入（这个锅多半是Hyper-V的）。进去之后发现可以识别分区，但是无法调整。第一次折腾以失败而告终。
第二次尝试
经过多方搜索，尝试以FedoraLive中调整分区。下载好镜像，重新创建虚拟机，安**livet-gui。还是无法调整。继续尝试以命令行方式调整。这中间也是多次调整失败，经过和豆包的多次深入交流最后终于将分区调整到目标大小。大体过程如下
1.激活目标卷组
sudo vgchange -ay trim\_3bd9ac4f\_8525\_4a24\_a0f7\_3bd16e072466
2.安装依赖工具（如未预装）
sudo dnf install -y lvm2 btrfs-progs
3.创建挂载点
sudo mkdir -p /mnt/btrfs_lv
4.挂载逻辑卷（使用真实设备路径）
sudo mount /dev/mapper/trim_3bd9ac4f_8525_4a24_a0f7_3bd16e072466-0 /mnt/btrfs_lv
5.缩**trfs文件系统到200GB
sudo btrfs filesystem resize 200G /mnt/btrfs_lv
6.验证Btrfs大小（可选，确认缩小生效）
sudo btrfs filesystem df /mnt/btrfs_lv
7.卸载文件系统（必须先卸载才能缩小LVM）
sudo umount /mnt/btrfs_lv
8.使用完整LV Path，并添加--resizefs自动同步文件系统
sudo lvreduce --force--yes--resizefs-L 200G /dev/trim\_3bd9ac4f\_8525\_4a24\_a0f7\_3bd16e072466/0
9.确认LVM大小
sudo lvs /dev/trim_3bd9ac4f_8525_4a24_a0f7_3bd16e072466/0
#输出中LSize应显示为200.00GiB
10.重新挂载并同步Btrfs到LV实际大小
sudo mount /dev/mapper/trim_3bd9ac4f_8525_4a24_a0f7_3bd16e072466-0 /mnt/btrfs_lv
sudo btrfs filesystem resize max /mnt/btrfs_lv sudoumount /mnt/btrfs_lv
#用blivet-gui验证（可选）
sudo blivet-gui
#启动后按F5刷新，确认逻辑卷大小为200GB
至此，表面上看，分区是已经调整好了，下一步就是在Hyper-V中调整虚拟磁盘大小了。结果，不出意外的问题来了，不管是在图形界面还是命令行都调小不了。得，接着找豆包聊去吧。
第三次尝试
经过我再一次的交流探讨，豆包告诉我，飞牛os采用的是RAID1+LVM2+btrfs的模式存储数据，光调整btrfs分区和LVM没用（我创建存储空间1的时候选择的是单盘basic模式）.还要把RAID1也调小才可以。它告诉我只要在gparted里把未分配空间调整到虚拟磁盘后面就可以。我信了，然后就跪了。我按照提示一步一步的调整RAID1。在gparted和blivet-gui中验证都显示调整调整成功，然后在命令行调小VHDX最大空间，调整为固定大小。经过漫长的等待，满心欢喜的挂载在飞牛上，启动，然后显示存储空间1未挂载，点击挂载显示内部错误。
山穷水复
接着内心毫无波澜的启动FedoraLive，按照豆包的说法是在调整RAID的时候超级块丢失，所以无法挂载。那问题多半是出在用gparted调整未分配空间的时候。（因为我调整玩btrfs分区后挂载飞牛，可以正常识别分区已经调小了，但是存储空间还是之前创建的大小。）现在说什么也晚了，经过挂载→失败→修复挂载失败→强制挂载→失败等多次尝试，豆包告诉我没招了，认命吧。至此，调整分区大小貌似是没戏了。
柳暗花明
既然调整分区不成功，那还有一个办法也能达到同样的目的：迁移数据。我在论坛和B站查找资料，都说可以用备份恢复来搞定。那行吧，接着搞起。创建一个200G的虚拟硬盘，在飞牛挂载，创建为存储空间2，启动备份，选择存储空间1的文件夹，下一步，？？？不能选择存储空间2？在文件管理里切换管理员视角只有下载？那还搞个毛线啊
普通模式倒是可以把存储空间1 的文件夹移动到存储空间2 ，可是Docker和应用咋办？ 我折腾这几个中午是为了啥
就在我毫无头绪的望着XTerminal的界面时，看到左侧的文件列表和右侧的监控。突然想到，我可不可以忽略调整分区，直接把文件复制过去不就行了（新创建的存储空间2选择的是和旧存储空间1一样的basic模式）。说干就干，先挂载再说
一、执行挂载操作
1.检查所有目标设备的文件系统类型
sudo blkid /dev/md127 /dev/md126 /dev/mapper/trim_9cc33db2_b77f_439f_915b_8a8837c4ff68-0 /dev/mapper/trim_33d44478_bf6d_43cb_afbc_4089d736f8b7-0 #输出示例（以 Btrfs 为例）： /dev/md127: TYPE=
2.记录下 TYPE 字段（如 btrfs/ext4/xfs）和 UUID（用于后续开机自动挂载）。确认 LVM 卷组与逻辑卷状态执行以下命令，检查 LVM 卷组是否已激活：
sudo vgdisplay # 查看卷组信息 sudo lvdisplay # 查看逻辑卷信息
#若卷组处于 inactive 状态，先激活卷组： sudo vgchange -ay # 激活所有卷组 sudo vgchange -ay # 激活所有卷组
3.创建挂载点目录挂载点
sudo mkdir -p /mnt/btrfs_900g /mnt/btrfs_200g
挂载 899.87GiB 逻辑卷
sudo mount -t btrfs -o defaults,noatime,ssd UUID=9a6a30dd-55e2-4c6e-9254-7a57f76154d0 /mnt/btrfs_900g
挂载 199.87GiB 逻辑卷
sudo mount -t btrfs -o defaults,noatime,ssd UUID=92a990e8-41d6-4b7c-97e5-22dbd93b53cd /mnt/btrfs_200g
4.验证挂载是否成功
查看 Btrfs 挂载情况
mount | grep btrfs
查看磁盘空间使用情况（包含挂载的分区）
df -h | grep btrfs
二、使用 rsync 复制所有文件 #rsync 的 归档模式（-a） 会保留文件的权限、时间戳、符号链接等属性，适合完整迁移数据。 #1. 基础复制命令（前台执行，显示进度）
sudo rsync -av --progress /mnt/btrfs_900g/ /mnt/btrfs_200g/
#参数说明： #-a：归档模式，等价于 -rlptgoD，保留所有文件属性； #-v：详细输出，显示复制的文件列表； #--progress：实时显示单个文件的复制进度； #注意路径末尾的 /：/mnt/btrfs_900g/ 表示复制目录内的所有内容，而非目录本身；如果不加 /，会在目标 分区生成 btrfs_900g 子目录。
#2. 后台执行（适合大文件 / 长时间复制，避免终端断开中断） #如果复制时间较长（比如包含大量小文件），建议用 nohup 后台执行，并输出日志：
sudo nohup rsync -av --progress /mnt/btrfs_900g/ /mnt/btrfs_200g/
#nohup：忽略终端断开信号，后台持续运行； #
#查看后台复制进度：
查看日志
tail -f /tmp/rsync_copy.log
或查看 rsync 进程
ps aux | grep rsync
三、验证复制结果（确保数据完整） #复制完成后，通过以下方式验证数据是否一致： #对比文件数量和大小
源分区文件总数和总大小
sudo find /mnt/btrfs_900g -type f | wc -l sudo du -sh /mnt/btrfs_900g
目标分区文件总数和总大小
sudo find /mnt/btrfs_200g -type f | wc -l sudo du -sh /mnt/btrfs_200g 两者的文件数和总大小应基本一致（差异通常是日志文件等实时变化的文件）。
code
