BCacheFS is the best Linux filesystem now that storage costs a premium.
You can mix devices of different sizes and types on bcachefs. You can have foreground and background devices to balance performance and also different compression settings for foreground and background transactions.
You can set replicas=N to the individual file or directory on bcachefs. For example files you can just re-download or re-build. Likewise you can set a higher number of copies to important files.
I've been using ZFS on my Linux servers for years and have pretty good experience with it. I've not been following Linux development too much. Is bcachefs usable/stable/reliable enough to replace it?
It's not as battle-tested like ZFS with 15+ years of field usage, but it's good enough for me and other users.
There's a NAS appliance called NASty and it shares publicly usage stats: https://nasty-telemetry.pages.dev/
Those numbers are NASty alone. There are more users on other systems.
If you have "refine until it's perfect and don't screw with things you don't understand" thoroughly ingrained, along with the dangers of overconfidence, you'll do fine with AI.
Not everyone gets it though, that's for sure.
And, if you want to know if it's mature, I'd trust the user reports over the one liners :)
That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers.
In fact they delivered the erasure coding for parity raid back in march this year.
The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is. I can only tell you that mixing different device tiers and having a per-file/directory replication setting is a god send specially in these times where storage costs more than gold.
> The thing is that as soon as you seriously give a chance to Bcachefs you see how good it is.
I'm pretty sure Bcachefs is amazing and better than Btrfs. I also think Zfs is amazing and better than Btrfs. Even so, I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.
> That might be the best thing happened to the project since now development can happen at its own pace without the clicky bait influencers.
A better approach might have been to just paused mainline merging instead of forcing being kicked out?
Eg "Hey Linus, Bcachefs is still in early development and I need to merge changes in a pace that is not compatible with Linux development process. So I'm going to pause for a while now and once it reaches maintenance status I will focus on submitting patches in a healthy pace that you can digest".
> I still use Btrfs because I know it is guaranteed to always be present on any Linux without any effort on my part.
I used to think that about ReiserFS, too. It was in the mainline kernel, development was snappy, and it solved some performance problems. I used it all over the place.
btrfs has one critical issue they don't fix: it blocks access to fs for minutes if you remove large files. I am not sure how this is acceptable for prod grade fs..
bcachefs on Arch is a bit better supported, we have the distro package maintainer in the bcachefs IRC channel, and I've never lagged on mainline support like ZFS has.
Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.
I think in a perfect world they should had put someone in between to mediate and curate patches while providing DKMS for urgent patches.
As for BTRFS I think its also pretty good. Its just that I have the impression its development is guided by the needs of its sponsors and sadly for us META doesn't need RAID5.
A lot of things were tried, people did try to mediate.
The particularly galling thing though was when I finally started looking - post split - comparing bcachefs PRs to other subsystems and especially XFS - I was being more conservative with what I considered a critical bugfix.
There was never a clear statement on what the issue was. What you guys got in public was about as much as I got.
All I can say is - going fast when you're stabilizing and getting bugfixes out the door is what you can and should be doing when you've invested in test coverage, test automation, keeping the codebase clean and asserted, and building up a community that works well together on testing and shaking things out.
bcachefs was already working at its own pace prior to being accepted in the kernel. It could have continued doing so for years until it was really "ready".
Instead it got kicked out because Kent constantly ignored the kernel's contribution rules and is unlikely it will ever be accepted back into the kernel.
I'd really appreciate it if we could drop the FUD over contribution rules. There are no such rules, it is explicitly Linus's way or the highway, and I already replied to that elsewhere.
And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum.
A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up.
Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.
You still don't understand the difference between new features and a bugfix? You're obviously very smart and at the same time you've shown a lack of social skills. If everyone can live with the rules and comply with Linus' orders except you, who's fault is it? I'm saying this in support of you: get your head out of your arse, take a break, vacation, party hard, hit a bong, relax, don't be at a computer for an entire day. I hope your social skills will have improved by then. If not, repeat the process and try new stuff out of your comfort zone.
Sounds strange, but there's more to life than sitting at a keyboard and monitor writing code and debugging it. Weird, right? I know. I've been doing that all my youth and then reality hit me. Can't say it was a bad thing.
You can't let Reddit guide your technical decisions.
The FS was marked experimental, so there is no urgency in fixing bugs or providing features in a certain cycle. Everyone using it knows what they got themselves into. You can still provide the DKMS module for faster fixes and features for anyone who wants to use BCacheFS more seriously for the time that the upstreaming process takes, but eventually it would have all been on mainline.
Asahi is taking a similar approach where they have their downstream kernel and push things upstream once they are mature.
That means the upstream kernel is not useful for running on that hardware now, but things are moving there eventually.
Press releases are sadly like that. Fujitsu's main page has it in the first line:
> FUJITSU-MONAKA is a Next-Gen Arm-based processor, set for release in 2027, designed to address the challenges of next-generation data centers with its unmatched performance and power efficiency.
I've dabbled in both Garage and RustFS. Both are good but IMO flawed.
Garage is good but has weird tooling and a terrible searchable term. You'll receive lots of garage doors and electrical gate results when searching for issues with it.
The biggest problem with Garage is the metadata on an sqlite. If you have a single file and that sqlite corrupts then all your data is unaddressable and treated as pile of anonymous blocks. If you have multiple servers you can rebuild the metadata but if you have only one server you REALLY need to make sure that file is backed up.
So if you use S3 as a backup you have to keep a backup of your backup.
RustFS is closer to Minio, but I hate the way they log stuff. They basically use journald as a metric database dumping json formatted lines about library calls and how long they took. Its hard to make sense of those logs. Its the kind of log not meant to be human readable but to render on a dashboard.
Why not just publish these as a prometheus endpoint?
Also high CPU usage for no reason. I also noticed RustFS constantly trashing disk and keeping 10% CPU usage while looping some health check I have no idea how to disable (I've tried RUSTFS_SCANNER_ENABLED=false and others with no results). And of course lots of json metrics on journald.
I personally prefer garage because my backup box sit at my office and I like not needing to listen to HDD sounds all day every day while Rustfs loops its health check.
Some stuff that is very niche but useful to me such as kerberized NFS has been broken forever. I don't remember if NFSv4 with krb5p ever worked to begin with.
>It also solved the issue I had with entering a password on FDE (full disk encryption) systems
I've fixed that with secure boot (my own keys, not Microsoft's) and TPM2. From that host I can run a program named Tang, which operates in conjunction with another program named Clevis.
On hosts without secure boot such as RPis and other ARM SBCs, Clevis will contact Tang at boot time and decrypt the disk.
Incidentally my x86 with secure boot has intel vPro so the KVM is not needed. The remaining sisters have a piece of lost technology used for decades to solve the KVM problem: serial (UART specifically) connections.
Some seasoned sysadmins might have memories of dialing their Sun servers serial ports for remote administration.
To me, it is a feature to have a password required at boot to unlock the drive. Relying on TPM for keymatter is convenient but comes with caveats I don't like. I don't personally trust that the boot chain and OS on a modern system are secure enough for this model to be similarly secure to using a passphrase properly. And if I care enough to try to secure something in this way, I definitely care enough to pick something that I believe would be at least truly secure at rest with a decent degree of certainty.
TPM based unlock does at least still fulfill the goal of ensuring data stored to disk is encrypted so that it can't easily be recovered from a discarded drive.
I am using Tang and Clevis without a TPM on an Orange Pi 5. The key is stored on my Tang server. No TPM required.
It is either on my LAN with that server available, or you will need to enter a key.
It am only trying to prevent casual snooping if it goes missing from my garage though. Anybody more sophisticated can have my garage YouTube browsing history.
This. I'm not fighting against a state level actor. My concern is some crackhead burglar stealing my stuff and then my personal data ending up in the hands of whoever buys the stolen goods.
I'm using a certain object storage implementation post minio enshitification. The software itself is great don't get me wrong but I've noticed their logs are basically unreadable. Its metrics and traces in json data meant to be rendered on a dashboard instead of being read by humans. It's also extremely verbose even at an INFO level.
Maybe just get these on an open telemetry endpoint instead? I also don't get why people send by default json logs to journald as it's clearly meant to be a replacement to syslog which is already a good standard.
I heard about Alpha in that it while being more powerful than x86 it wasn't as alien as the competition. The boards had PCI slots and looked like normal PCs, it had Windows NT and Linux. So if your Exchange server was not handling the load you moved it to Alpha and it was good.
It also seems faith in IA64 was the meteor that killed most of these self developed RISC architectures.
FWIW Alpha pretty quickly went with mainly PCI + few legacy ISA slots for considerable chunk of the line, unlike competition which used proprietary buses that might have been faster but meant extra level of exotic in procurement
A VAR I worked with back in the day made great scratch for a good number of years flogging MS SQLServer on Alpha for the performance boost, which was apparently more than enough to justify the price premium for those that needed it.
Apple private relay is very flawed but on the other hand most sites that view connections originating from VPN as suspicious seem to be ok with Apple Private Relay. If you have VPN on your router private relay on top of it could be a good way to do ip address laundering.
I find it pretty annoying that iCloud Private Relay does not work together with VPNs.
I mainly use VPNs to access bank sites (or other sites that are annoying enough to use IP country as a proxy for traffic being evil/legitimate) when traveling, but I often forget to turn off the VPN afterwards, and then spend the rest of my day browsing from my home IP (that terminates the VPN), which would have been hidden behind Private Relay if I'd actually been browsing from my home Wi-Fi.
Cross-site/app ad targeting getting creepy good despite using different browser profiles for work/personal browsing etc. is usually a good tell (at least on IPv6).
You can mix devices of different sizes and types on bcachefs. You can have foreground and background devices to balance performance and also different compression settings for foreground and background transactions.
You can set replicas=N to the individual file or directory on bcachefs. For example files you can just re-download or re-build. Likewise you can set a higher number of copies to important files.
reply