- 主题:[求助]BTRF文件系统出错，如何修复？
我原先是luks+lvm+ext4，没有重新分区，只是把lvm的几个lv合并了。所以是luks+lvm+btrfs。
【 在 Dazzy 的大作中提到: 】
: luks，lvm再叠一层btrfs，这种复杂玩法，我是不敢托付宝贵数据的。
: luks+btrfs到顶了。
:
: ...................
--
FROM 120.229.210.*
我的xfs也出过问题，后来一查有xfs_repair，一运行就修复了。
【 在 hgoldfish 的大作中提到: 】
: 我的 xfs 也崩过。不知道怎么修复，最后把备份恢复一下了事。
: ext4 用得少，大家碰到崩溃的情况没有？
:
--
FROM 120.229.210.*
ext4真是稳啊，有问题都是掉电后重新fsck就好了。
【 在 Dazzy 的大作中提到: 】
: 非硬件问题引起的没遇过。这个真是稳如狗。ext4以当前的需求看，功能比较素哈。
:
: #发自zSMTH@Redmi Note 7
--
FROM 120.229.210.*
我这次的btrfs问题不知道是不是硬件问题，只是这个硬盘是sandisk plus480G，买了半年了，上面装了debian，另一个致钛ssd 512G，装arch，两个硬盘都挂同一个机器上。
用arch时间较久一点，而且经常用完电脑直接在arch上休眠，下次回来继续，就这样持续了快2周，昨天突然间发现sandisk的SSD出现input/output错误，然后上面btrfs文件系统旧挂了。
【 在 hgoldfish 的大作中提到: 】
: 我的几次 btrfs 多是硬件原因坏掉了。
: 非硬件原因的话，其实也发生过几次。主要是我给 vmware 的虚拟机分区弄了 nocow 选项，好像配合 btrfs 的 Direct IO，容易出现 checksum 的问题。
:
--
FROM 120.229.210.*
估计要悲剧了。。不然你看看 btrfs rescue 有没有用吧。如果没有。。
【 在 ttaudi 的大作中提到: 】
: 今晚找来一个SSD，把出问题硬盘的数据dd到新SSD上，运行check --repair，结果还是不行。
: [code=text]
: root@archlinux: ~ # btrfsck --repair --force /dev/san/root
: ...................
--
FROM 183.253.147.*
折腾一晚上，能看到目录了，但是好多文件访问不到，出现input/output错误。根据这些文件，我回忆起一些事情，觉得这次btrfs出错完全是我自己搞出来的。
是我在arch上打开了装有debian的btrfs文件系统，然后休眠了。接着下次开机时进到debian系统，进行了读写操作，之后关机回到arch，继续用了几天后发现安装又debian的btrfs文件系统访问有问题。这样看的话，装有debian的硬盘上数据估计很难恢复了。
也就是说这次是人祸，正常使用的话，btrfs应该不会出现这样的问题。
--
FROM 120.229.210.*
有可能，debian和arch内核版本可能不一样，btrfs可能存在不兼容更新差异。
【 在 ttaudi 的大作中提到: 】
: 折腾一晚上，能看到目录了，但是好多文件访问不到，出现input/output错误。根据这些文件，我回忆起一些事情，觉得这次btrfs出错完全是我自己搞出来的。
: 是我在arch上打开了装有debian的btrfs文件系统，然后休眠了。接着下次开机时进到debian系统，进行了读写操作，之后关机回到arch，继续用了几天后发现安装又debian的btrfs文件系统访问有问题。这样看的话，装有debian的硬盘上数据估计很难恢复了。
: 也就是说这次是人祸，正常使用的话，btrfs应该不会出现这样的问题。
: ...................
--
FROM 119.130.155.*
这是 arch 的 btrfs 不知道磁盘已经发生变化，还在用内存里面的 free space cache 以及树结构写数据。结果把文件系统给破坏坏了。
【 在 ttaudi 的大作中提到: 】
: 折腾一晚上，能看到目录了，但是好多文件访问不到，出现input/output错误。根据这些文件，我回忆起一些事情，觉得这次btrfs出错完全是我自己搞出来的。
: 是我在arch上打开了装有debian的btrfs文件系统，然后休眠了。接着下次开机时进到debian系统，进行了读写操作，之后关机回到arch，继续用了几天后发现安装又debian的btrfs文件系统访问有问题。这样看的话，装有debian的硬盘上数据估计很难恢复了。
: 也就是说这次是人祸，正常使用的话，btrfs应该不会出现这样的问题。
: ...................
--
FROM 120.33.8.*
应该就是这样了，感觉这种覆盖型的破坏很难把文件恢复出来，数据本身就是错的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这是 arch 的 btrfs 不知道磁盘已经发生变化，还在用内存里面的 free space cache 以及树结构写数据。结果把文件系统给破坏坏了。
:
: 【 在 ttaudi 的大作中提到: 】
: : 折腾一晚上，能看到目录了，但是好多文件访问不到，出现input/output错误。根据这些文件，我回忆起一些事情，觉得这次btrfs出错完全是我自己搞出来的。
--
FROM 14.26.11.*
双系统双启动危险，也很丑陋。跑虚拟机吧。
分享一点:
如果用户用无分区(partitionless)的btrfs，再在这个机器上用windows的启动盘，btrfs的磁盘内容可能会被windows毁了。
【 在 ttaudi 的大作中提到: 】
:
: 折腾一晚上，能看到目录了，但是好多文件访问不到，出现input/output错误。根据这些文件，我回忆起一些事情，觉得这次btrfs出错完全是我自己搞出来的。
:
: 是我在arch上打开了装有debian的btrfs文件系统，然后休眠了。接着下次开机时进到debian系统，进行了读写操作，之后关机回到arch，继续用了几天后发现安装又debian的btrfs文件系统访问有问题。这样看的话，装有debian的硬盘上数据估计很难恢复了。
:
#发自zSMTH@Redmi Note 7
--
FROM 119.129.238.*