Bcachefs storage plugin for Proxmox VE

[Max500]

Hi all,

Proxmox has no native bcachefs storage support, until now the only option was adding it as "Directory" storage, which doesn't support snapshots on raw disks.

I built a plugin (based on the official Btrfs one) that adds bcachefs integration: snapshot support for raw images, it also supports the usual content types (images, rootdir, vztmpl, backup, iso, snippets), except the import one.

Grab it from here: https://github.com/MmAaXx500/pve-storage-plugin-bcachefs
I'd love to hear feedback on it.

Consider it experimental, so be cautious what data you trust it with.

 

[Johannes S]

Isn't bcachefs still developed outside the kernel due to it's maintainers inability to cooperate with other people by following the kernel developers processes?
Then I will pass

 

[ness1602]

So if ZFS but people are using it.

 

[alexskysilk]

So if ZFS but people are using it.

This. The linux kernel community isnt an exclusive arbiter of what makes "Good" software, and as dkms exists that isnt a reason TO and NOT TO use anything.

The reason to avoid bcachefs has nothing to do with internal Linux Kernel politics, its because filesystems are complicated and bcachefs is young.

 

[uzumo]

I think it’s extremely risky that he alone—rather than the organization as a whole—is the one motivated to keep the software updated.

It’s far too dangerous to run the risk of losing access to our data if he is no longer able to update it and the kernel is updated.

No matter how excellent a piece of software may be, anything that lacks continuity for server use—even if only one person is guaranteeing it—is out of the question.

Furthermore, what I want most is to be able to continue using the software with its current settings and performance until the next major update. I don’t need minor updates that add various features the developers think are interesting.

*If someone told you, “You need an update to access that data, and the update costs money,” it would sound a lot like that software everyone’s been talking about.

 

[alexskysilk]

I think it’s extremely risky that he alone—rather than the organization as a whole—is the one motivated to keep the software updated.

That is true. ReiserFS is a cautionary tale.

It’s far too dangerous to run the risk of losing access to our data if he is no longer able to update it and the kernel is updated.

That isnt. bcachefs is dkms loaded, and you can use it pretty much on any Linux system. you dont actually need to use a plugin for pve either, it functions normally as a filestore.

 

[Johannes S]

The reason to avoid bcachefs has nothing to do with internal Linux Kernel politics, its because filesystems are complicated and bcachefs is young.

I beg to differ, to quote myself:

Not including zfs is mainly for legal reasons so not comparable. Also zfs isn't just a one-man-show and has multiple comanies funding development and is mature enough not to loose data. In contrast bcachefs developer Kent Overstreet wanted to violate kernel workflow due to Bugs which might cause dataloss. Sorry, but if you can't work with others due to your new shiny toy still too buggy it shouldn't be used in the first place for anything important.

J

Post in thread 'Shared Remote ZFS Storage'

May 1, 2026

but zfs isnt also in the kernel and you are ok with using it?

That's mainly for legal reasons so not comparable. Also zfs isn't just a one-man-show and has multiple comanies funding development and is mature enough not to loose data. In contrast bcachefs developer Kent Overstreet wanted to violate kernel workflow due to Bugs which might cause dataloss. Sorry, but if you can't work with others due to your new shiny toy still too buggy it shouldn't be used in the first place for anything important.

• Johannes S

• 

Of course distributions (like Ubuntu, Proxmox and TrueNAS already did for zfs) can decide to tolerate the envolved riscs. But imho it‘s quite different to accept riscs coming from a legal Situation ( which might not even apply for non-american companies ) or the riscs coming from the shenangians of the main developer of a filesystem not able to cooperate with others.

 

[alexskysilk]

That's mainly for legal reasons so not comparable.

How? even if I was to accept the premise (which isnt even true) it still doesnt explain how one option is "superior" to the other (which, after all, is what comparison means.) There is a conflict in licensing that prevents the inclusion of zfs modules in-kernel, but thats a choice- the Linux kernel isnt licensed by gpl3 as a matter of law. If Linus wanted to, he can change it. bcachefs is not in-kernel for virtually the same reason- Linus doesnt want it to be if its not within his rules. Its not a criticism, just observation.

can decide to tolerate the envolved riscs.

What risks?

riscs coming from the shenangians of the main developer of a filesystem not able to cooperate with others.

This is nebulous at best. "not cooperating with others" is meaningless in context; the fact that Kent decided he didnt want to operate by Linus' rules for in-kernel inclusion doesnt make the software better or worse. and with dkms the whole point is mooted anyway.

You are entitled to your opinions, as is everyone, but dont expect to just present them as fact and be taken seriously.

 

[Johannes S]

What risks?

In case of zfs: Getting sued by Oracle/Sun. In case of bcachefs: Loosing data due to critical bugs. I mean Kent Overstreets (bcachefs main developers) argument in his conflict with Torvalds was basically "My filesystem is still experimental and might lead to dataloss so I need to submit patches even after the deadline for their integration to avoid this". Imho if a filesystem is still to risky too use then it shouldn't be included in the kernel in the first place. Now as a company I could of course decide to integrate it nontheless. But for this I might need help from the developers in case I stumble over some issue and personally I wouldn't be able to trust the bcachefs developers enough to feel comfortable with it. On the other hand I think it's rather unlikely that Oracle will actually sue potential offenders of zfs license especially outside of the american legalsphere.

 

[alexskysilk]

In case of zfs: Getting sued by Oracle/Sun

oh for the love of god. this trope doesnt seem to ever die.

OpenZFS is based on CDDL, which Oracle can't revoke: Sun Microsystems released ZFS under the Common Development and Distribution License (CDDL) in 2005. The CDDL explicitly includes a worldwide, royalty-free, irrevocable patent license from the contributor (Sun/Oracle) for the code they released. Oracle cannot retroactively pull that code back or sue people for using the open-source code Sun published. There WAS a question with infringing on NetAPP patents but all of them have long expired.

I mean Kent Overstreets (bcachefs main developers) argument in his conflict with Torvalds was basically "My filesystem is still experimental and might lead to dataloss so I need to submit patches even after the deadline for their integration to avoid this".

No. just no. The golden rule of kernel development is strict division of labor: new features go in during the "merge window," and only bug fixes go in during the "Release Candidate" (RC) phases. Overstreet repeatedly violated this protocol. During the 6.16 cycle, he submitted a massive change called "journal-rewind" (a major repair feature) right in the middle of the RC phase. When Linus and other senior devs (like ext4 maintainer Ted Ts'o) told him "no, this is too risky and violates the rules," Kent argued that the rules shouldn't apply when data integrity is on the line, pushed back, and eventually resubmitted it anyway. This is not a "code quality" issue, its a personality conflict issue. I actually agree with the Kernel maintenance team's position, but it IS NOT A QUALITATIVE CRITICISM OF THE CODE ITSELF.

Your overall point regarding the code (and the developer's) maturity stands- it's definitely not ready for production use, but that could change with time despite the soap opera.