求助， lvm 卷 xfs 文件系统，在经过我一番操作后，提示输入输出错误
yao990 · 2018-07-14 00:53:30 +08:00 via Android · 8324 次点击这是一个创建于 2349 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天手贱，先是用 lvreduce 命令将分区缩小至原来的一半，然后又用 lvextend 命令扩充至原来的大小，然后挂载，挂载可以正常挂载，当用 ls 列出文件时就提示无法打开目录，输入输出错误。 后执行 vgs.lvs.lvdisplay.pvdisplay.df.等命令均显示正常（或以我的水平还无法看出哪里有问题）， 但想要进入分区查看文件时就提示输入输出错误，尝试 xfs_repair.xfs_metadump.xfs_growfs 等命令均提示输入输出错误。
现求助各位大侠该怎么办？
 |
1
xcai 2018-07-14 03:09:17 +08:00 via Android
xfs 文件系统不支持缩小
|
 |
3
defunct9 2018-07-14 08:25:15 +08:00 via iPhone  1
开 ssh，我也救不了了
|
 |
4
heiher 2018-07-14 08:41:51 +08:00
默认情况下 lvreduce 不会在缩小分区时同时缩小分区中的文件系统呀，缩小后可能有元数据的写入释放的空间，文件系统的数据结构被破坏了。。。下次记得 lvreduce 加个 -r 参数。
|
 |
5
tempdban 2018-07-14 08:42:32 +08:00 via Android
输入输出错误，把 dmesg 打出来我看一眼
|
 |
6
yao990 OP @tempdban
由于完整信息太长，v2ex 无法回复，所以麻烦移步 https://s.cxice.com/thread-2974.htm 先谢谢了 @heiher 那这现在咋整？ @defunct9 嗯？开 ssh 然后呢？ |
|
8
tempdban 2018-07-14 09:51:09 +08:00 via Android
从你的 log 里没看到任何 umount 的操作，先 umount 再 xfs_repair
|
|
9
tempdban 2018-07-14 09:52:31 +08:00 via Android
[242061.505790] attempt to access beyond end of device
[242061.505799] dm-2: rw=7217, want=6444519751, limit=5862637568 [242061.505818] XFS (dm-2): metadata I/O error: block 0x1801f9145 ("xlog_iodone") error 5 numblks 64 [242061.505825] XFS (dm-2): xfs_do_force_shutdown(0x2) called from line 1222 of file fs/xfs/xfs_log.c. Return address = 0xffffffffc053ae20 [242061.505836] XFS (dm-2): Log I/O Error Detected. Shutting down filesystem [242061.505839] XFS (dm-2): Please umount the filesystem and rectify the problem(s) [242239.788000] sdc: sdc1 |
|
10
tempdban 2018-07-14 09:53:49 +08:00 via Android
dm-2: rw=7217, want=6444519751, limit=5862637568
把硬盘再 lv 再扩大吧，没有原来的的大。 还有你的数据大概率找不全了 |
|
11
yao990 OP |
 |
12
reus 2018-07-14 09:56:31 +08:00
lvextend 可能用到了其他的 extent，所以读不到原来的数据。如果使用原来的 extent，可能可以修复
应该先缩小文件系统，再缩小 lv 的，但你直接缩小 lv 了 lvextend 应该指定原来的 pv 和 extent，但你可能没有指定 lvm 是可以恢复原先的配置的，在 /etc/lvm/backup, archive 都有记录，而你选择了 lvextend …… 挂载之后 ls 出现错误，这时候就不应该做任何操作，但你还执行了 xfs_repair 等等，很可能造成进一步的破坏 连续几次失误…… |
|
13
yao990 OP @tempdban 这个应该怎么操作？之前执行的是 lvextend -l +100%FREE /dev/mapper/cenos-home
|
|
14
yao990 OP @reus 手贱阿，本来好好的，啥事没有，可是脑子一抽，就想试试缩小文件系统，结果一发不可收拾。。。。。这现在该怎么整？
|
|
17
reus 2018-07-14 10:17:06 +08:00
@yao990 如果你能找到人现场帮你修，或者可以救回来。或者先放着不要动，等以后你知道怎么修了，再看看有没有救，不要再这里动一下那里动一下了……
|
|
18
reus 2018-07-14 10:19:42 +08:00
|
|
20
tempdban 2018-07-14 10:22:59 +08:00 via Android
要是想完全和以前一样，不是不能，但是超级难。
要是能忍受一点点的数据丢失那好办了 |
|
21
yao990 OP |
 |
22
henglinli 2018-07-14 11:47:52 +08:00 via iPhone
建议用 zfs 或者 btrfs
|
|
24
reus 2018-07-14 15:03:39 +08:00
@yao990 这个可以恢复 vg，但是 xfs 有没有被你的 xfs_repair 之类的命令破坏就不知道了。如果你没动过文件系统，那恢复 vg 是肯定没问题的，问题就在于你用了 xfs_repair 之类的…………
恢复旧 vg 前把现在的 vg 也备份一下，存到其他地方，以备恢复…… |
 |
25
msg7086 2018-07-14 17:23:09 +08:00
@reus 我在前一个帖子里已经明确提醒过在 dd 备份之前不要做任何破坏性操作。
如果只是提示 IO 错误的话，repair 应该还没有成功执行才对，这是我的猜测。 |
|
26
yao990 OP @reus 我恢复 vg 了，现在除了输入输出错误以外，其他的都和之前一样了。而且我也发现 vg 为什么和以前不一样了，是在一块硬盘后面有 4MB 的剩余空间，我在执行 lvextend -l +100%FREE /dev/mapper/cenos-home 时，将这 4MB 也一块扩展进去了。
所以现在就剩下清除 xfs 日志一条路可走了吗？ @tempdban 你说的忍受一点点的数据丢失是指的清除 xfs 日志吗？另外，一点点的数据丢失大概有多少？因为盘里有一部分（大概 40%）文件很重要，一部分（ 60%）文件可有可无，，所以如果要丢数据能不能丢在可有可无的这一部分里？如果这个丢失和写入时间有关，丢失的是最后写入的部分的话，那没关系，刚好最后两天写入的都是不重要的，大概有接近 100GB 大小。 |
|
28
msg7086 2018-07-14 17:53:13 +08:00
丢失和写入时间无关。
已经丢了的数据也不会因为你现在向老天爷祈祷所以给你换点数据丢…… |
 |
29
Damenly1 2018-07-14 17:55:33 +08:00
@yao990 那就什么都不要动，备份设备， 去 [email protected] 发邮件，可能还有得救。
|
|
30
tempdban 2018-07-14 17:55:52 +08:00 via Android
到不是日志，我怕你把 ag 租和 inode 搞丢了。
还有输入输出错误就再看 dmesg,实在搞不定就 dd 然后 repair |
|
32
yao990 OP @tempdban 我执行 vg 恢复以后，研究里一下午 dmesg，但什么都没研究出来，倒是发现之前那个报大小不一致的错误现在不报了。
https://c.cxice.com/thread-2975.htm 这是最新的 dmesg，还请过目。 |
|
36
tempdban 2018-07-14 19:04:47 +08:00 via Android
我是觉得没啥问题了… 你可以 彻底 umount 掉 然后 repair
|
|
37
yao990 OP @tempdban 直接 repair 会报错，也是输入输出错误，repair -L 还没试。你说的那个会丢失部分数据的方法是什么？
|
|
39
tempdban 2018-07-14 20:14:36 +08:00 via Android
谁能知道丢多少…
|
|
41
tempdban 2018-07-14 20:47:36 +08:00 via Android
你先 dd 备份一下啊
|
|
43
yao990 OP @tempdban 这是执行 xfs_repair -n /dev/mapper/centos-home 的结果，请过目
Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... agi unlinked bucket 5 is 4068101 in ag 4 (inode=8594002693) agi unlinked bucket 20 is 24568916 in ag 4 (inode=8614503508) agi unlinked bucket 56 is 165262648 in ag 4 (inode=8755197240) agi unlinked bucket 57 is 165262649 in ag 4 (inode=8755197241) agi unlinked bucket 58 is 165262650 in ag 4 (inode=8755197242) agi unlinked bucket 59 is 165262651 in ag 4 (inode=8755197243) agi unlinked bucket 61 is 165262653 in ag 4 (inode=8755197245) agi unlinked bucket 62 is 165262654 in ag 4 (inode=8755197246) agi unlinked bucket 41 is 4173929 in ag 3 (inode=6446624873) agi unlinked bucket 42 is 4173930 in ag 3 (inode=6446624874) sb_fdblocks 1267635907, counted 1267644099 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 6446624873, would move to lost+found disconnected inode 6446624874, would move to lost+found disconnected inode 8594002693, would move to lost+found disconnected inode 8614381716, would move to lost+found disconnected inode 8614503508, would move to lost+found disconnected inode 8755197240, would move to lost+found disconnected inode 8755197241, would move to lost+found disconnected inode 8755197242, would move to lost+found disconnected inode 8755197243, would move to lost+found disconnected inode 8755197245, would move to lost+found disconnected inode 8755197246, would move to lost+found Phase 7 - verify link counts... would have reset inode 6446624873 nlinks from 0 to 1 would have reset inode 6446624874 nlinks from 0 to 1 would have reset inode 8594002693 nlinks from 0 to 1 would have reset inode 8614381716 nlinks from 0 to 1 would have reset inode 8614503508 nlinks from 0 to 1 would have reset inode 8755197240 nlinks from 0 to 1 would have reset inode 8755197241 nlinks from 0 to 1 would have reset inode 8755197242 nlinks from 0 to 1 would have reset inode 8755197243 nlinks from 0 to 1 would have reset inode 8755197245 nlinks from 0 to 1 would have reset inode 8755197246 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. |
|
44
yao990 OP @tempdban 我刚尝试执行 xfs_repair -L 清空日志，但提示设备忙，直接 xfs_repair 也提示设备忙
|
 |
45
ryd994 2018-07-15 02:42:53 +08:00 via Android
没硬盘就去买啊
数据值钱还是硬盘值钱，想想清楚 作死不嫌快 |
|
46
tempdban 2018-07-15 11:07:04 +08:00 via Android
这些 inode 谁也不知道是什么文件，你胆大就搞，不敢就放在那。
设备忙是因为还有文件描述符没有关闭，fuser 不用每一步就找我确认一下，我说话不用付什么责任的，操作的人还是你 |
|
47
yao990 OP @tempdban 太感谢了，非常感谢，要不是你的提示，我这会儿还像无头苍蝇一样乱撞。我刚才一个个检查进程，关闭了所有和目标卷有关的进程，然后重新 repair，成功找回了所有文件！太谢谢了
|
 |
48
likuku 2018-07-15 12:33:41 +08:00
自作孽不可活，请节哀。
LVM 和 xfs/ext4 来回 resize 以前也玩过多次，有成功也有失败，扩充容易缩小很麻烦必须非常谨慎。 没有可信赖离线备份 /异地备份前提下，还是剁手先。 真这么喜欢折腾，zfs 优先。btrfs 最近几年被坑很多次，还是不推荐它。当然，可信备份不厌其烦。 |
|
49
likuku 2018-07-15 12:36:10 +08:00
看来是主角光环已经恢复了，恭喜。
关于这类高危实验，依然再次推荐在 virtualbox 环境下测试就可以了。 |
Select Language