Hacker News Reader

Comment by snapplebobapple | Hacker News Reader

btrfs isn't that terrible for desktop use right now. I mean, I wouldn't personally use it, I lost data on it a couple times four plus years ago, but it's come a long way since then. (my preference is keep everything I care about on a fileserver like truenas running zfs with proper snapshotting, replication and backup and live dangerously on the desktop testing out bcachefs, but I recognize not everyone can live my life and some people just want a laptop with a reasonable filesystem resistant to bit rot.

View on HN

I recently found out Fedora defaults to btrfs with zstd compression enabled by default. Seems to work well enough.

On my personal devices I prefer BTRFS' snapshotting ability over the risk of having to restore from backup at some point.

Is there decent encryption support, or are we stuck using full disk encryption at the block level?

I don't know, I just use FDE because I don't trust filesystem level encryption to protect against the many side channel attacks one can inject into a running system. LUKS is good enough for me.

It looks like there's slow but steady progress on FSCRYPT support on BTRFS: https://bkhome.org/news/202403/linux-kernel-btrfs-supports-f... No idea what kind of state it is in currently.

The latter at this point.

How is bcachefs for personal use these days?

The political situation for bcachefs is far from good, with pressure from Linus and a CoC violation.

The net effect will likely delay stability.

https://www.phoronix.com/news/Bcachefs-Fixes-Two-Choices

https://www.phoronix.com/news/Linux-CoC-Bcachefs-6.13

Honestly the political situation will probably be a /good/ thing for long term stability, because I get a few months without any stupid arguments with upstream and finally get to write code in peace :)

It sucks for users though, because now you have to get my tree if you want the latest fixes, and there's some stuff that should be backported for forwards compatibility with the scalability improvements coming soon [1].

[1]: https://www.patreon.com/posts/more-expensive-116975457

I'm hoping to use your filesystem when it's ready.

Everyone wishes that this were easier for you.

I have to say I do see Linus' point though. Mainline is for stuff that's production-ready and well tested.

Having said that it's a great initiative and I hope it becomes ready for prime time. I think btrfs is taking too long and is infused with too much big tech interest.

Don't worry about the users, we'll manage somehow, it's such a tiny burden compared to the actual development. I'm just really happy to see you're not discouraged by the petty political mess and keep pushing through. Thank you!

Hey Kent, I just wanted to thank you for all your hard work. For those of us that would like to use the code in your tree to get the latest fixes and help with testing, I was wondering how hard it would be to set up OBS to automatically build and package fresh kernels and userland tools for OpenSUSE/Debian/Arch/etc, nightly and/or for each tag. I think it would help adoption as well as comfort, knowing that your improvements will arrive as soon as they are available.

I personally stopped compiling your code in my personal repo when bcachefs was upstreamed. It often was a pain to rebase against the latest hardened code and I'm happier since it's upstream. I use your fs for 7-8 years now and I hope your latest changes to the disk format will actually improve mount performance (yes I'm one of the silent "victims" you were talking about). I hope nothing breaks...

Anyway thank you for your work and I wish you all the best on the lkml and your work.

Echoing the sibling comment Kent, bcachefs is a really wonderful and important project. The whole world wants your filesystem to become the de-facto standard Linux filesystem for the next decade. One more month of LKML drama is a small price for that (at LKML prices).

I've been running bcachefs on one of my laptops since it hit linux stable. Just wanted to say thank you for all your constant work on it.

I switched back to the arch default kernel for my 32TB home media server, would you recommend going back to compiling your kernel for the time being?

Not unless you've been hitting a bug you need the fix for

Been using it since 6.7 on my root partition. Around 6.9 there were issues that needed fsck. Now on 6.12 it is pretty stable already. And fast, it is easy to run thousands of Postgres tests on it. Not something zfs or btrfs really could do without tuning...

So if you're a cowboy, now it's a good time to test. If not, wait one more year.

I haven't lost any data yet. It did something stupid on my laptop that looked like it was about to repeat btrfs's treatment of my data a few months ago but 15 minutes of googling on my phone and I figured out the right commands to get it to fix whatever was broken and get to a bootable state. I'm a decade away from considering it for a file server holding data I actually care about but as my main desktop and my laptop file system (with dotfiles backed up to my git instance via yadm and everything I care about nfs mounted in from my fileservers) it's totally fine.

I believe the main bcachefs mantainer does not advocate production use yet

We're still six months or so from taking the experimental label off, yeah. Getting close, though: filesystem-is-offline bugs have slowed to a trickle, and it's starting to be performance issues that people are complaining about.

Hoping to get online fsck and erasure coding finished before taking off experimental, and I want to see us scaling to petabyte sized filesystems as well.

Oh wow... That's actually really fast progress all things considered. Well done! I really hope all the... umm... misunderstandings get worked out because you're doing great work.

It's all stuff that's been in the pipeline for a long time.

(And we'll see when online fsck and erasure coding actually land, I keep getting distracted by more immediate issues).

Really, the bigger news right now is probably all the self healing work that's been going on. We're able to repair all kinds of damage without an explicit fsck now, without any user intervention: some things online, other things will cause us to go emergency read only and be repaired on the next mount (e.g. toasted btree nodes).

One of the choices you've made that I really like is sharing the kernel and userspace filesystem code so directly in the form of libbcachefs. I get the impression this means the kernel can do practically everything userspace can, and vice versa. (I think the only exception is initialising devices by writing a superblock, although the kernel can take over the initialisation of the rest of the filesystem from that point onwards? And maybe turning passphrases into keys for encrypted-fs support which does an scrypt thing?)

As well as giving you really powerful userspace tools for manipulating filesystems, this also suggests that a stripped down busybox module for bcachefs could consist of superblock writing and pretty much nothing else? Maybe a few ioctls to trigger various operations. "Just leave it all to the kernel."

After a bit of peer pressure from a friend, I decided ended up using btrfs with my laptop about three months ago. It’s been fine thus far.

Emphasize on ‘this far’…

To me that kind of experiment is the equivalent of changing your car brake for something ‘open source’, maybe better, maybe not.

But when you need them you’re going to want to make sure they’re working.

How much of an assurance do you want? I've been using btrfs on my desktop for 3+ years. And I've also experienced no issues thus far.

The btrfs volume on my Synology NAS is 6 years old now, with 24/7 operation (including hosting web sites with constant read/write database activity) and going through several volume resize operations. No issues.

Reply on news.ycombinator.com