首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
V2EX  ›  Linux

求助, lvm 卷 xfs 文件系统,在经过我一番操作后,提示输入输出错误

  •  
  •   yao990 · 313 天前用 Android 发布 · 3853 次点击
    这是一个创建于 313 天前的主题,其中的信息可能已经有所发展或是发生改变。

    今天手贱,先是用 lvreduce 命令将分区缩小至原来的一半,然后又用 lvextend 命令扩充至原来的大小,然后挂载,挂载可以正常挂载,当用 ls 列出文件时就提示无法打开目录,输入输出错误。 后执行 vgs.lvs.lvdisplay.pvdisplay.df.等命令均显示正常(或以我的水平还无法看出哪里有问题), 但想要进入分区查看文件时就提示输入输出错误,尝试 xfs_repair.xfs_metadump.xfs_growfs 等命令均提示输入输出错误。

    现求助各位大侠该怎么办?

    52 回复  |  直到 2018-07-15 15:58:02 +08:00
        1
    xcai   313 天前 via Android
    xfs 文件系统不支持缩小
        2
    yao990   313 天前 via Android
    @xcai 哎,我也是执行了操作以后才知道。所以现在还有没有什么办法能挽救?
        3
    defunct9   313 天前 via iPhone   ♥ 1
    开 ssh,我也救不了了
        4
    heiher   313 天前
    默认情况下 lvreduce 不会在缩小分区时同时缩小分区中的文件系统呀,缩小后可能有元数据的写入释放的空间,文件系统的数据结构被破坏了。。。下次记得 lvreduce 加个 -r 参数。
        5
    tempdban   313 天前 via Android
    输入输出错误,把 dmesg 打出来我看一眼
        6
    yao990   313 天前
    @tempdban
    由于完整信息太长,v2ex 无法回复,所以麻烦移步
    https://s.cxice.com/thread-2974.htm
    先谢谢了


    @heiher 那这现在咋整?


    @defunct9 嗯?开 ssh 然后呢?
        7
    heiher   313 天前
    @yao990 xfs_repair 试试看呢
        8
    tempdban   313 天前 via Android
    从你的 log 里没看到任何 umount 的操作,先 umount 再 xfs_repair
        9
    tempdban   313 天前 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   313 天前 via Android
    dm-2: rw=7217, want=6444519751, limit=5862637568
    把硬盘再 lv 再扩大吧,没有原来的的大。
    还有你的数据大概率找不全了
        11
    yao990   313 天前
    @tempdban @heiher
    # umount /home
    umount: /home:目标忙。
    (有些情况下通过 lsof(8) 或 fuser(1) 可以
    找到有关使用该设备的进程的有用信息)
    # umount -l /home
    # xfs_repair /dev/mapper/centos-home
    xfs_repair: cannot open /dev/mapper/centos-home: 设备或资源忙
        12
    reus   313 天前
    lvextend 可能用到了其他的 extent,所以读不到原来的数据。如果使用原来的 extent,可能可以修复
    应该先缩小文件系统,再缩小 lv 的,但你直接缩小 lv 了
    lvextend 应该指定原来的 pv 和 extent,但你可能没有指定
    lvm 是可以恢复原先的配置的,在 /etc/lvm/backup, archive 都有记录,而你选择了 lvextend ……
    挂载之后 ls 出现错误,这时候就不应该做任何操作,但你还执行了 xfs_repair 等等,很可能造成进一步的破坏
    连续几次失误……
        13
    yao990   313 天前
    @tempdban 这个应该怎么操作?之前执行的是 lvextend -l +100%FREE /dev/mapper/cenos-home
        14
    yao990   313 天前
    @reus 手贱阿,本来好好的,啥事没有,可是脑子一抽,就想试试缩小文件系统,结果一发不可收拾。。。。。这现在该怎么整?
        15
    reus   313 天前
    @yao990 放弃吧,以后重要文件做好备份
        16
    yao990   313 天前 via Android
    @reus 一点办法都没有了吗?😭
        17
    reus   313 天前
    @yao990 如果你能找到人现场帮你修,或者可以救回来。或者先放着不要动,等以后你知道怎么修了,再看看有没有救,不要再这里动一下那里动一下了……
        18
    reus   313 天前
        19
    tempdban   313 天前 via Android
    @reus 他 lazy umount 的 之前压根没 repair 还有救
        20
    tempdban   313 天前 via Android
    要是想完全和以前一样,不是不能,但是超级难。
    要是能忍受一点点的数据丢失那好办了
        21
    yao990   313 天前
    @tempdban @reus 我刚才在 /etc/lvm/archive/下发现了执行压缩操作时创建的还原点文件,是不是把这个还原点还原回去就好了?
        22
    henglinli   313 天前 via iPhone
    建议用 zfs 或者 btrfs
        23
    yao990   313 天前 via Android
    @henglinli 这都是后话了,现在我就想怎么恢复过来。。。。
        24
    reus   313 天前
    @yao990 这个可以恢复 vg,但是 xfs 有没有被你的 xfs_repair 之类的命令破坏就不知道了。如果你没动过文件系统,那恢复 vg 是肯定没问题的,问题就在于你用了 xfs_repair 之类的…………

    恢复旧 vg 前把现在的 vg 也备份一下,存到其他地方,以备恢复……
        25
    msg7086   312 天前
    @reus 我在前一个帖子里已经明确提醒过在 dd 备份之前不要做任何破坏性操作。
    如果只是提示 IO 错误的话,repair 应该还没有成功执行才对,这是我的猜测。
        26
    yao990   312 天前
    @reus 我恢复 vg 了,现在除了输入输出错误以外,其他的都和之前一样了。而且我也发现 vg 为什么和以前不一样了,是在一块硬盘后面有 4MB 的剩余空间,我在执行 lvextend -l +100%FREE /dev/mapper/cenos-home 时,将这 4MB 也一块扩展进去了。
    所以现在就剩下清除 xfs 日志一条路可走了吗?


    @tempdban 你说的忍受一点点的数据丢失是指的清除 xfs 日志吗?另外,一点点的数据丢失大概有多少?因为盘里有一部分(大概 40%)文件很重要,一部分( 60%)文件可有可无,,所以如果要丢数据能不能丢在可有可无的这一部分里?如果这个丢失和写入时间有关,丢失的是最后写入的部分的话,那没关系,刚好最后两天写入的都是不重要的,大概有接近 100GB 大小。
        27
    yao990   312 天前
    @msg7086 确定没有成功执行,因为 repair 也提示输入输出错误
        28
    msg7086   312 天前
    丢失和写入时间无关。
    已经丢了的数据也不会因为你现在向老天爷祈祷所以给你换点数据丢……
        29
    Damenly1   312 天前
    @yao990 那就什么都不要动,备份设备, 去 linux-xfs@vger.kernel.org 发邮件,可能还有得救。
        30
    tempdban   312 天前 via Android
    到不是日志,我怕你把 ag 租和 inode 搞丢了。
    还有输入输出错误就再看 dmesg,实在搞不定就 dd 然后 repair
        31
    yao990   312 天前 via Android
    @msg7086 说的也是啊,感觉这是随机的。
        32
    yao990   312 天前
    @tempdban 我执行 vg 恢复以后,研究里一下午 dmesg,但什么都没研究出来,倒是发现之前那个报大小不一致的错误现在不报了。
    https://c.cxice.com/thread-2975.htm
    这是最新的 dmesg,还请过目。
        33
    yao990   312 天前
    @Damenly1 我发个邮件试试吧,不知道看邮件的人能不能看懂中文?
        34
    Damenly1   312 天前
    @yao990 用英文。记得用纯文本格式
        35
    yao990   312 天前
    @Damenly1 好的,谢谢了
        36
    tempdban   312 天前 via Android
    我是觉得没啥问题了… 你可以 彻底 umount 掉 然后 repair
        37
    yao990   312 天前 via Android
    @tempdban 直接 repair 会报错,也是输入输出错误,repair -L 还没试。你说的那个会丢失部分数据的方法是什么?
        38
    yao990   312 天前 via Android
    @tempdban 另外大概会丢失多少文件?
        39
    tempdban   312 天前 via Android
    谁能知道丢多少…
        40
    yao990   312 天前 via Android
    @tempdban 额,不会全丢吧?
        41
    tempdban   312 天前 via Android
    你先 dd 备份一下啊
        42
    yao990   312 天前 via Android
    @tempdban 没那么大的硬盘啊,,,,,,
        43
    yao990   312 天前
    @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   312 天前
    @tempdban 我刚尝试执行 xfs_repair -L 清空日志,但提示设备忙,直接 xfs_repair 也提示设备忙
        45
    ryd994   312 天前 via Android
    没硬盘就去买啊
    数据值钱还是硬盘值钱,想想清楚
    作死不嫌快
        46
    tempdban   312 天前 via Android
    这些 inode 谁也不知道是什么文件,你胆大就搞,不敢就放在那。
    设备忙是因为还有文件描述符没有关闭,fuser
    不用每一步就找我确认一下,我说话不用付什么责任的,操作的人还是你
        47
    yao990   312 天前 via Android
    @tempdban 太感谢了,非常感谢,要不是你的提示,我这会儿还像无头苍蝇一样乱撞。我刚才一个个检查进程,关闭了所有和目标卷有关的进程,然后重新 repair,成功找回了所有文件!太谢谢了
        48
    likuku   312 天前
    自作孽不可活,请节哀。

    LVM 和 xfs/ext4 来回 resize 以前也玩过多次,有成功也有失败,扩充容易缩小很麻烦必须非常谨慎。

    没有可信赖离线备份 /异地备份前提下,还是剁手先。

    真这么喜欢折腾,zfs 优先。btrfs 最近几年被坑很多次,还是不推荐它。当然,可信备份不厌其烦。
        49
    likuku   312 天前
    看来是主角光环已经恢复了,恭喜。

    关于这类高危实验,依然再次推荐在 virtualbox 环境下测试就可以了。
        50
    tempdban   312 天前 via Android
    @yao990 看你 43 楼的日志还是有 inode 会丢了的,去 lost+found 找
        51
    yao990   312 天前 via Android
    @likuku 谢谢
        52
    yao990   312 天前 via Android
    @tempdban 好的,谢谢啦
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4104 人在线   最高记录 5043   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 21ms · UTC 09:06 · PVG 17:06 · LAX 02:06 · JFK 05:06
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1