- 主题:btrfs修了十多年bug了,依然还是那么烂
不过还好,十年前我用btrfs没几天发现它崩了,就再没用它了,用回ext4之后再没这方面的烦恼。
除此之外,三星的f2fs文件系统也是个修不好的坑货。
--
FROM 171.213.130.*
我路由器的sd卡格式化成f2fs,数据全丢。
【 在 gameplayer 的大作中提到: 】
: f2fs哪里坑了?我看好多手机都在用,没听说出啥问题啊
:
--
FROM 171.213.142.*
你也知道群辉是nas产品在用,无论照片还是电影,都是不会频繁修改的只读文件,随便用个文件系统都没问题。
生产环境敢用来存自己创造的,不断修改的文件的文件系统,才是靠谱的。
【 在 ttaudi 的大作中提到: 】
: 恕我孤陋寡闻,今天才发现群晖用btrfs,群晖作为全球NAS巨头,那么多年用市场验证btrfs,是不是说明即使btrfs之前有bug,但是也那么长时间的修修补补也该稳定了吧。
--
FROM 171.213.144.*
我的pve和pvb备份服务器也用的zfs。zfs修bug的时间比btrfs长多了,更稳定也正常。
【 在 iwannabe 的大作中提到: 】
: 那只是nas的家用用途,企业用途是作为外挂存储,比如作为k8s的pvc
: qnap在企业级nas里用的是zfs
--
FROM 171.213.136.*
不是我小看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.*
我不用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.*