- 主题:btrfs修了十多年bug了，依然还是那么烂
我的pve和pvb备份服务器也用的zfs。zfs修bug的时间比btrfs长多了，更稳定也正常。
【 在 iwannabe 的大作中提到: 】
: 那只是nas的家用用途，企业用途是作为外挂存储，比如作为k8s的pvc
: qnap在企业级nas里用的是zfs
--
FROM 171.213.136.*
其实也不完全是btrfs，是魔改版，感兴趣可以去搜一下
【 在 ttaudi 的大作中提到: 】
: 恕我孤陋寡闻，今天才发现群晖用btrfs，群晖作为全球NAS巨头，那么多年用市场验证btrfs，是不是说明即使btrfs之前有bug，但是也那么长时间的修修补补也该稳定了吧。
--
FROM 1.202.8.*
我没有参与bcachefs的开发。一个文件系统能达到企业级品质稳定下来需要10年以上的时间，bcachefs还要继续努力。btrfs这么多年，经过suse和rehdat的打磨，品质已经好很多了。很多nas厂商实际上已经广泛的使用btrfs在产品环境了。
如果有btrfs开发者高手，对产品环境维护和开发btrfs并回馈开源社区有兴趣，欢迎联系我。
【 在 iconquer 的大作中提到: 】
: @colyli for bcachefs
--
FROM 120.245.64.*
不是我小看btrfs，前一阵爆的雷，现在才擦完屁股，这种bug不知道还有多少。
8 月 6 日 08:11 EDT - Linux 存储 - Btrfs 日志树损坏 - 32 条评论
6 August 08:11 AM EDT - Linux Storage - Btrfs Log Tree Corruption - 32 Comments
在 Linux 6.15.3+ 版本中，越来越多的 Btrfs 文件系统用户报告了日志树损坏问题。幸运的是，现在已提交了一个修复程序到 Linux 6.17 Git，并计划回移植到最近的稳定内核版本。
On Linux 6.15.3+ there have been increased reports of log tree corruption being hit by users of the Btrfs file-system. Fortunately, a fix has now been submitted for Linux 6.17 Git and then for back-porting to the recent stable kernel versions.
--
FROM 171.213.150.*
数据保住没
【 在 poocp (慢速随机指标) 的大作中提到: 】
: 不是我小看btrfs，前一阵爆的雷，现在才擦完屁股，这种bug不知道还有多少。
: 8 月 6 日 08:11 EDT - Linux 存储 - Btrfs 日志树损坏 - 32 条评论
: 6 August 08:11 AM EDT - Linux Storage - Btrfs Log Tree Corruption - 32 Comments
: 在 Linux 6.15.3+ 版本中，越来越多的 Btrfs 文件系统用户报告了日志树损坏问题。幸运的是，现在已提交了一个修复程序到 Linux 6.17 Git，并计划回移植到最近的稳定内核版本。
--
FROM 223.104.68.*
我不用btrfs，十多年来一直不用。
【 在 ttaudi 的大作中提到: 】
: 数据保住没
--
FROM 171.213.150.*
一个受害者的留言：
不久前（约一年前）我设置了一个这样的系统：
在第二个 NVMe 硬盘上使用 Luks2+btrfs。加密方式为 AES-XTS，采用 256 位密钥，同时搭配使用 zstd 压缩级别 7 的 btrfs 文件系统。该分区挂载到/data 目录下，用于存储那些即使丢失我也毫不畏惧的数据（如 Steam 游戏、音乐、电视剧等）。通过 fstab 和 crypttab 结合密钥文件实现自动挂载，无需快照或复杂的子卷设置，我只需享受压缩带来的好处。整个过程中从未发生过非正常关机的情况。
它的压缩效果很好，当我发现 300GB 的存储空间实际仅使用了 215GB 时，简直太棒了。直到有一天，压缩效果变得如此出色，以至于文件被压缩到了零字节大小。
这个文件系统“在遇到一些不可恢复的错误之前不需要运行 fsck”……
我绝对不会再信任那个文件系统了。幸好丢失的数据对我而言并不重要。
I had one not long ago(1 year)
Luks2+btrfs on the second nvme. Aes-xts plain, 256bit keysizs + btrfs with zstd lvl 7 compression. Mounted in /data and used to hold crap that I would not be afraid if I lose (Steam games, music, series, etc). Automount with fstab+crypttab using a keyfile, no snapshots, no complex sub volume setups, I just wanted to benefit from the compression. No unclean shutdowns whatsoever.
It had good compression and I've hit a level where 300GB was actually using only 215GB, fantastic. Until the day where compression worked so awesomely that compressed to zero.
This filesystem "does not need fsck" until you hit some unrecoverable errors...
I would not trust that filesystem never again. Luckily it was data that I would not care much if I lose it.
--
FROM 171.221.52.*
btrfs 可没保证不丢数据。
它保证的是，断电的时候，文件系统不会坏啊！
【 在 poocp 的大作中提到: 】
: 一个受害者的留言：
: 不久前（约一年前）我设置了一个这样的系统：
: 在第二个 NVMe 硬盘上使用 Luks2+btrfs。加密方式为 AES-XTS，采用 256 位密钥，同时搭配使用 zstd 压缩级别 7 的 btrfs 文件系统。该分区挂载到/data 目录下，用于存储那些即使丢失我也毫不畏惧的数据（如 Steam 游戏、音乐、电视剧等）。通过 fstab 和 crypttab 结合密钥文
: ...................
--
FROM 27.152.9.*
这个是不是用了新内核导致的，如果不用新内核，是不是会稳定一些？
【 在 poocp (慢速随机指标) 的大作中提到: 】
: 一个受害者的留言：
:
: 不久前（约一年前）我设置了一个这样的系统：
:
--
FROM 223.104.87.*