[flagged]
On my personal devices I prefer BTRFS' snapshotting ability over the risk of having to restore from backup at some point.
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 net effect will likely delay stability.
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].
Everyone wishes that this were easier for you.
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.
Anyway thank you for your work and I wish you all the best on the lkml and your work.
So if you're a cowboy, now it's a good time to test. If not, wait one more year.
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.
(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).
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."
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.
Snapshots a bit less so, but even for my laptop this would be useful, mostly for backups (that is: create snapshot, backup that, and then delete the snapshot – this is how I did things on FreeBSD back in the day). A second use case would be safer system updates and easier rollbacks – not useful that often, but when you need it, it's pretty handy.
https://github.com/openzfsonwindows/ZFSin
There is also Microsoft's own ReFS:
Apache v2 and GPLv3 were made explicitly compatible while providing different kinds of freedom.
It's not really. Many aspects of the license are free-er, but that's not what causes the incompatibility. The GPL does not have any kind of clause saying code that is distributed under too permissive of a license may not be incorporated into a derived/combined work. It's not that it's weak copyleft, it is that it contains particular restrictions that makes it incompatible with GPL's restrictions.
BSD licenses do not have that incompatible restriction (= are freer than CDDL, in that aspect) and can be compatible with the GPL.
Some have argued that this may not actually constitute an incompatibility, but not many are keen to "fuck around and find out" with Oracle's lawyers. So here we are.
Oracle could spend 10 minutes and clear this up, but the fact they don't should be fear enough about any large company shipping with OpenZFS code.
See Oracle vs Google
That said, they did relicense DTrace to GPL a few years back. but I don't really know the details on that, or how hard it was, or if that's also possible for OpenZFS.
When I publish code I don't pick any license. It's just free for anyone to use for whatever. I don't like the GPL for this, it's way too complicated. I don't want to deal with that.
It's a shame some legal BS like that is holding back the deployment of a great filesystem like ZFS.
That's not good in all cases as in some jurisdictions it means that any use is forbidden...
It's also really only a big thing in the US. Here in Europe things are usually settled amicably and the courts frown on people taking up their time with bullshit. They only really get involved if all else fails and only really for businesses. Nobody really cares about software licensing except the top 200 companies.
I'm admittedly a bit biased though. Unfortunately I sometimes have to deal with our internal legal dept. in the US (I'm based in Europe) and I find them such nasty people to deal with. Always really pushy. This made me hate them and their trade.
In Windows, Satya would need to write Larry a check. It would probably be hefty.
Edit: there was a time that this was planned for MacOS.
https://arstechnica.com/gadgets/2016/06/zfs-the-other-new-ap...
That was a joyous prospect. A single volume manager/filesystem across all UNIX platforms would be wonderful.
We had the UNIX wars of the 1990s. Since Linux won, they have been replaced by the filesystem wars.
I see no reason for the down votes.
_Windows Drivers work the same way and nobody huffs and puffs about that_
I'd love to have an intelligent discussion on how one person's opinion on licensing issues stacks up against the legal teams of half the fortune 50's. Licensing doesn't work on "well, I didn't mean it THAT way."
> Warning: Occasionally, the dkms package might not compile against the newest kernel packages in Arch. Using the linux-lts kernel may provide better compatibility with out-of-tree kernel modules, otherwise zfs-dkms-staging-gitAUR backports compatibility patches and fixes for the latest kernel package in Arch on top of the stable zfs branch
So... my system might fail to boot after updates. If I use linux-lts, it might break less often. Or I can use zfs-dkms-staging-git, and my system might break even less often... or more often, because it looks like that's installing kernel modules directly from the master branch of some repo.
As a practical matter I could care less if my system fails to boot because of "license issues" or some other reason, I just want the lawyers to sort their shit out so I don't have to risk my system becoming unbootable at some random inopportune time. Until then, I've never hit a btrfs bug, so I'm going to keep on using it for every new build.
When it comes to filesystems, I very much appreciate the "it just works" experience – not having a working filesystem is not having a working system and it a pain to solve.
Again, all of this has been a while. Maybe it's better now and I'm not opposed to trying, but I consider "having to use DKMS" to be a downside of ZFS.
> Note: Unlike Btrfs and ZFS, the CRC32 checksum only applies to the metadata and not actual data.
https://wiki.archlinux.org/title/XFS
---
bcachefs isn't stable enough to daily drive.
> Nobody sane uses bcachefs and expects it to be stable
—Linus Torvalds (2024)
https://lore.kernel.org/lkml/CAHk-%3Dwj1Oo9-g-yuwWuHQZU8v%3D...
The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure.
And I wouldn't say that filesystem people in general wear rose colored glasses; I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson.
The point is he doesn't have to understand details of the code to see bug reports and code churn and bug fix commits and have a reasonable idea of whether it's stable enough for end users. I would trust him to make that call more than a "filesystem guy", in fact.
> The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure.
Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale.
> And I wouldn't say that filesystem people in general wear rose colored glasses;
Perhaps that's what you see through your rose colored glasses? (sorry, just a cheeky dig).
> I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson.
Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification.
I'm not singling out filesystem developers or any one person or even software development specifically. All complex projects need advocates and input from outside stakeholders (users, other software, etc) for this exact reason, is that those deep in the guts of it usually don't understand all perspectives.
No, that's not enough, and I would not call that kind of slagging good communication to users.
Seeing bugfixes go by doesn't tell you that much, and it definitely doesn't tell you which filesystem to recommend to users because other filesystems simply may not be fixing critical bugs.
Based on (a great many) user reports that I've seen, I actually have every reason to believe that your data is much safer on bcachefs than btrfs. I'm not shouting about that while I still have hardening to do, and my goal isn't just to beat btrfs, it's to beat ext4 and xfs as well: but given what I see I have to view Linus's communications as irresponsible.
> Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale.
No, our testing situation is crap, and we need leadership that says more than "not my problem".
> Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification.
Well, he had a point, and you don't want to be artificially injecting fsyncs because for applications that don't need them that gets really expensive. Fsync is really expensive, and it impacts the whole system.
Now, it turned out there is a clever and more practical solution to this (which I stole from ext4), but you simply cannot expect any one person to know the perfect solution to every problem.
By way of example, I was in an argument with Linus a month or so ago where he was talking about filesystems that "don't need fsck" (which is blatently impossible), and making "2GB should be enough for anyone" arguments. No one is right all the time, no one has all the answers - but if you go into a conversation assuming the domain experts aren't actually the experts, that's not a recipe for a productive conversation.
It is enough. Users need to be told when something is not stable or good enough.
> Seeing bugfixes go by doesn't tell you that much, and it definitely doesn't tell you which filesystem to recommend to users because other filesystems simply may not be fixing critical bugs.
Cherry picking what I wrote. Bugfixes, code churn, and bug reports from users. It certainly tells someone like Linus a great deal without ever reading a single line of code.
> Based on (a great many) user reports that I've seen, I actually have every reason to believe that your data is much safer on bcachefs than btrfs. I'm not shouting about that while I still have hardening to do, and my goal isn't just to beat btrfs, it's to beat ext4 and xfs as well: but given what I see I have to view Linus's communications as irresponsible.
Being risk adverse with my data, I think Linus's comment is a helpful and responsible one to balance other opinions.
> No, our testing situation is crap, and we need leadership that says more than "not my problem".
No. Testing is crap because developers and employers don't put enough time into testing. They know what has to be done, leadership has told them what has to be done, common sense says what has to be done. They refuse to do it.
When code gets to a pull request for Linus it should have had enough testing (including integration testing via linux-next) that it is ready to be taken up by early user testers via Linus' tree. Distros and ISVs and IHVs and so on need to be testing there if not linux-next.
> Well, he had a point, and you don't want to be artificially injecting fsyncs because for applications that don't need them that gets really expensive. Fsync is really expensive, and it impacts the whole system.
No it was never about fsync, it was about data writes that extend a file hitting persistent storage before inode length metadata write does. By careful reading of posix it may be allowed, as a quality of implementation for actual users (aside from administrator-intensive high end file servers and databases etc from SGI), it is the wrong thing to do. ext3 for example solved it with "ordered" journal mode (not fsync).
You can accept it is poor quality but decide you will do it anyway, but you can't just say it's not a problem because you language-lawyered POSIX and found out its okay, when you have application developers and users complaining about it.
> By way of example, I was in an argument with Linus a month or so ago where he was talking about filesystems that "don't need fsck" (which is blatently impossible), and making "2GB should be enough for anyone" arguments. No one is right all the time, no one has all the answers - but if you go into a conversation assuming the domain experts aren't actually the experts, that's not a recipe for a productive conversation.
I didn't see that so I can't really comment. It does not seem like it provides a counter example to what I wrote. I did not say Linus is never wrong. I have got into many flame wars with him so I would be the last to say he is always right. Domain experts are frequently wrong about their field of expertise too, especially in places where it interacts with things outside their field of expertise.
You came in with an argument to authority, and now you're saying you disagree with that authority yourself, but you trust that authority more than domain experts?
I don't think you've fully thought this through...
Everyone believes what they read in the news, until they see it reporting on something they know about - and then they forget about it a week later and go back to trusting the news.
I wrote what I wrote. I didn't "come in" with the argument to authority though, that was you (or perhaps the OP you replied to first). Anyway, I gave examples where domain experts are myopic or don't actually have the expertise in what other stakeholders (e.g., users) might require.
Otherwise you'll get situations where your 100GB VM image will use over a TB of physical disk space.
It's a shame really that this still isn't solved.
Many downsides to CoW are also present with many common alternatives (i.e. thin LVM2 snapshots). Best to leave all of that off if you're using spinning rust or native compression features, though.
Are you sure your TRIM is working and the VM disk image is compacting properly? It's working for me but not really great for fragmentation.