Hacker News Reader

Hacker News

Comment by arjvik | Hacker News Reader

Parent Full thread

arjvik

How is bcachefs for personal use these days?

View on HN

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.

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).

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!

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.

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

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 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.

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.

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."

Reply on news.ycombinator.com