linux这resize2fs的命令咋那么久，请教
我不是买了个12t的pdd硬盘嘛。原来nas装的是12t+3t+3t+2t 4盘。
操作系统装2t上，当年脑子进水了把剩下的三块盘做了个逻辑卷。
现在想把两个3t的都拿掉。
我删了10t的电影，总共还剩下6t数据，我打算先resize2fs把逻辑卷降到7t再把两块盘pvmove之后拿掉。
结果resize2fs这个操作已经跑了10小时了。
按理说我空间都空了这又不牵扯到挪硬盘就是标记一下的事情怎么要那么久的。
我记得当年用这个命令扩展空间是瞬间就好的。。 要是这个操作是把7t数据全都挪个窝的话，那没准真不少时间。 每秒100m。7t是19小时 本帖最后由 生存戰略 于 2024-8-24 20:10 编辑
一般的文件删除，只会删除指向数据位置的快捷方式。
删了10t电影，并不会得到10T的空白连续空间。而是有不连续的10T空间，被标记为“此块数据没人用，可以新写入数据覆盖”。
虽然我不明白具体的逻辑，但可以想像，如果分区刚格式化，存储的数据都是连续的，有确定的连续空白，resize当然快。
已经用了10T，就算删除文件，这时候resize，也一样需要像整理硬盘碎片一样搬运现有数据，空出连续的大空间。
结论是大概只能等。 本帖最后由 子虚乌有 于 2024-8-25 23:28 编辑
我是个沙雕。
根本不需要resize2fs
应该是这条命令lvreduce -L 7000G -f-v -y /dev/mapper/vgroup1-lv1
白白硬盘空转了1天，数据丢没丢不好说。反正check出一堆逻辑错误来
更新，直接lvreduce才是沙雕。
数据都没了
本帖最后由 Midnight.Coup 于 2024-8-25 13:36 编辑
lvreduce 不管里面有没有数据会直接切下去，配合 --resizefs 选项用先让文件系统缩一下，再切就没问题了
EXT4 还喜欢分散存，直接切大概率丢数据
Midnight.Coup 发表于 2024-8-25 13:35
lvreduce 不管里面有没有数据会直接切下去，配合 --resizefs 选项用先让文件系统缩一下，再切就没问题了
EX ...
啊 kde 的 partition manager 还蛮省心的，luks+lvm+btrfs 调分区大小都能一键处理 这个命令来扩大分区当然是快的，但是压缩空间就可能有已经用掉的区块，得移动，还是机械盘，慢也是正常的吧 wdw 发表于 2024-8-25 15:18
这个命令来扩大分区当然是快的，但是压缩空间就可能有已经用掉的区块，得移动，还是机械盘，慢也是正常的吧 ...
我看网上有人抱怨说从100t弄到80t一周都没结束 求求不要用 lvm 了，我看见 lvm 的脑袋都大了，zfs 和 btrfs 等现代的文件系统都覆盖了 lvm 的功能了，这一层加的时候容易，想移去的时候就想打人了。而且对 lvm 的操作特别容易犯错，楼主的操作我就犯过，lvm 层操作和 fs 层操作没同步，dmesg 一堆写错误，还好没写到奇奇怪怪的位置，ext4 后来修复回来了。 ryanz 发表于 2024-8-25 16:03
求求不要用 lvm 了，我看见 lvm 的脑袋都大了，zfs 和 btrfs 等现代的文件系统都覆盖了 lvm 的功能了，这一 ...
这次新添了快12t的，我把两个3t的拿走以后就把数据弄到新的12t的上去然后把旧的12t删掉逻辑卷。
确实是当时欠考虑。 ryanz 发表于 2024-8-25 16:03
求求不要用 lvm 了，我看见 lvm 的脑袋都大了，zfs 和 btrfs 等现代的文件系统都覆盖了 lvm 的功能了，这一 ...
机械的话 LVM2+EXT4 还是挺成熟的，Btrfs 更适合 SSD 用，Btrfs 命令行操作起来其实也容易出问题 lvm调整别看国内的操作文章...都tm不说后果的...
你不检查下你文件有损坏没么? litel 发表于 2024-8-25 17:57
lvm调整别看国内的操作文章...都tm不说后果的...
你不检查下你文件有损坏没么? ...
还在弄呢，暂时没得查 尴尬了，换了硬盘。操作系统进不去了，能ping通不能ssh
nas又没有显示器。 原来是mount不上逻辑卷了
mount/dev/mapper/vgroup1-lv1 /data
mount: /data: wrong fs type, bad option, bad superblock on /dev/mapper/vgroup1-lv1, missing codepage or helper program, or other error.
哭了 文件系统损坏了吧，感觉数据大概率找不回来了
如果将存储由外向内看作类似“物理设备>RAID>LVM>FS”的层级结构，扩容的时候要从最外向内逐层操作，缩容的时候相反从最内向外
扩容搞错了顺序一般也就是报错但会维持现状，缩容搞错了数据就没了 illuminati 发表于 2024-8-25 23:21
文件系统损坏了吧，感觉数据大概率找不回来了
如果将存储由外向内看作类似“物理设备>RAID>LVM>FS”的层级 ...
试了半天，估计是丢了。
希望我以前冷备的硬盘还在。
痛心啊，收集多年的施法材料肯定是没了。 本帖最后由 linux40 于 2024-8-25 23:47 编辑
Midnight.Coup 发表于 2024-8-25 16:56
机械的话 LVM2+EXT4 还是挺成熟的，Btrfs 更适合 SSD 用，Btrfs 命令行操作起来其实也容易出问题 ...
Btrfs在断电之后大概率再次开机没法读取文件系统，我自己就遇到过一次，之后再也不敢用。Ext4、xfs和zfs断电之后，文件系统都能修复。别问我为啥要断电，很多时候kernel崩溃了不得不断电再操作。我最近就遇到过ax201、qcnfa765以及某块蓝天的主板因不同原因让kernel崩溃或卡住。
对了螃蟹网卡的驱动也会让kernel崩溃，不过当时我用的aarch64。 linux40 发表于 2024-8-25 23:40
Btrfs在断电之后大概率再次开机没法读取文件系统，我自己就遇到过一次，之后再也不敢用。Ext4、xfs和zfs ...
断电就炸btrfs两个可能
1. 早就炸了，btrfs才发现；
2. 你这个硬盘型号对某些命令阳奉阴违。 现代linux下（指6.10）要么zfs（你需要RAID5/6）要么btrfs。
只不过btrfs因为是CoW FS所以需要改变一下认知。 hanyuwei70 发表于 2024-8-26 07:44
断电就炸btrfs两个可能
1. 早就炸了，btrfs才发现；
2. 你这个硬盘型号对某些命令阳奉阴违。 ...
可能是2吧，印象中只有btrfs是这么设计的。 hanyuwei70 发表于 2024-8-26 07:45
现代linux下（指6.10）要么zfs（你需要RAID5/6）要么btrfs。
只不过btrfs因为是CoW FS所以需要改变一下认知 ...
啊，我还是用的ext4 子虚乌有 发表于 2024-8-26 08:42
啊，我还是用的ext4
先跑跑e4defrag再缩吧 子虚乌有 发表于 2024-8-26 08:42
啊，我还是用的ext4
如果你不想去学习btrfs怎么用，那用ext4也挺好的。 linux40 发表于 2024-8-26 08:55
先跑跑e4defrag再缩吧
逻辑卷已经彻底干掉了，数据没了。
我都格式化了 许多年前，本来想着多块硬盘拼到一个目录里，然后要是升级硬盘就缩一下逻辑卷再把最小的那块取出来换个大的再扩逻辑卷
结果，哎 喜闻乐见数据火葬场 本帖最后由 scikirbypoke 于 2024-8-26 13:51 编辑
命令我都不敢乱输的，GUI好歹有个丢数据的提示，命令回车了就没了
我见过一个用dd迁移系统结果把Windows覆盖的，后来发现是没检查盘符
页:
[1]