Hacker News Reader

Comment by sieve | Hacker News Reader

bcachefs exists outside of any drama. I switched my pools to it from ZFS last year and it is working swimmingly. What ZFS use case do you have that bcachefs does not solve? Only thing I can think of is zfs send/receive and I never used that.

Both bcachefs and ZFS are social problems, not technical. Nothing stops a distro from shipping ZFS as part of their kernel. Except a legal interpretation of whether CDDL and GPL2.0 allow that marriage.

View on HN

I think bcachefs social problems come in part from its hidden technical deficits. “FS implemented as A DB” is a big, leaky idea which undermines userspace claims like “Filesystem code doesn't know about locking or journalling”. Restart-safety being required everywhere is quite a tax.

That leakiness becomes drama when it’s not acknowledged; the energy gets converted to last-minute bugfixes or convoluted workarounds. I’d argue separately that totalization (more than just btrees) threatens a software’s role, and that motivated role confusion forced bcachefs removal from the kernel.

Indeed they're non-technical problems, but really blocking ones. As a user, I dont want to have my filesystem and Kernel have a possibility of going out of sync leading to an unusable system during a regular update.

The biggest attractor towards BcacheFS for me was the possibility of that cohesion. All the technical merits were a bonus as ZFS does already what I wish for. That factor went away with BcacheFS choosing to not get mainlined into Linux Kernel. Now we have two good filesystems outside the kernel :-(

Reply on news.ycombinator.com