Incredible that they don't clearly say what the exploit is and what OS/hardware/apps is/are vulnerable. Still, quite a lot of interesting info about the modern ad delivery networks sewer system...
Another recommendation for mise, in my case it has already fully replaced brew, stow and direnv since I started using it this January, and it has many more features I'm not using yet (secret management, tasks, automation, ...), all from a single rust binary.
Also, unlike homebrew/linuxbrew, the install path for apps can be set to anywhere and is fully portable (it's all relative symlinks).
So far I never had any issue with it or any backward incompatibilities when upgrading, despite the very frequent releases and constant new features. The developer also seems very security minded (he immediately added a "minimum release age" feature for all apps when the trivy github action debacle was made public)
I think the reviews should also include the social aspect of these filesystems...
There is and have been many promising and exciting FS to replace the old boring ones, but for storage you not only want to avoid technical issues but also maintainer(s) drama...
drama matters because most users don't want to have their favourite FS randomly removed from the kernel unexpectedly after some OS update :)
That said I certainly hope that one day the technical advantage of bcachefs will be so overwhelming that maybe the decision to remove it will be overturned. And if big vendors make it their default FS the bus factor will disappear (even if unofficially you'd still be the sole maintainer, but no one cares about that in the enterprise world...)
> most users don't want to have their favourite FS randomly removed from the kernel
True. But when you look at this, isn't the deeper problem that Linux remains such a monolith, and there's a stark difference between "included" and "not included" in the kernel. It's now over 35 years old. The fact that we can't have stable APIs and develop more out-of-tree drivers is not a strength, it's a weakness.
Even old Unix systems like SVR4 managed to have stable, public driver interfaces, despite being rather proprietary. FreeBSD manages to have drivers in its ports tree, with a stable API for a given major version. What makes Linux so special that it can't manage this?
I understand all of the arguments about why this has to be so. But... they might have made sense in the early days, but after 35 years it screams of immaturity. Plenty of other systems, including other open source systems, manage to do this, including having versioned interfaces so things aren't set in stone. Linux remains right at the extreme end of guaranteeing nothing. I've long thought this was unnecessary and counterproductive.
the downside of a stable API is more non-free drivers. the API being unstable is a strength in that it forces driver developers to use a GPL compatible license in order to get their drivers into the kernel, or it motivates the FOSS community to develop alternative drivers that are GPL compatible.
and, i believe i read somewhere that this is not an inability to stabilize the API but a conscious decision to not promise a stable API expressly because it creates the effect i described.
To answer the original question, most people who care about their filesystem at all care about its stability. Not just "does it work now" but also "will it work and improve over time". Infighting puts the future at risk.
But you might want to check out the bus factor on btrfs too; when a maintainer says "but we've saved Facebook billions and billions of dollars!", calls for the other filesystem maintainer to be ejected from the community, then quits to join Anthropic a month later - that's not a vote of confidence.
I'd be very happy if people could just stop bringing up drama and us factors. We put it behind us a year ago, but it seems not everyone got the memo.
Other things: since no companies sponsoring its development had any interest in raid 5/6, which is mostly a home enthusiast thing.
Western Digital picked up this work last year and is slowly getting through the new design without the write hole, I think we'll see working raid 5/6 in the next year or two.
> Other things: since no companies sponsoring its development had any interest in raid 5/6, which is mostly a home enthusiast thing.
I've used RAID-Z1/2/3 at a couple of jobs: yes IOps is suck-y, but if it's for backups of other systems, or the central logging server, or network monitoring (Suricata, Snort), sometimes your priority is cheap/bulk.
I'm currently in the HPC space, and Lustre is a thing here, and it has tiered storage via policies: you can (e.g.) put your recent/hot data on NVMe, but older/colder bits on spinning rust on ZFS.
Might end in a new bcachefs fork beeing included back into mainline. If companies sponsor a few fulltime devs working on the new fork, we finally might have a stable enterprise ready CoW filesystem.
Thought about a real fork going in its own direction. I would love to use bcachefs in all our products. But the current state does not qualify for usage within enterprise environments. Any ideas how to get that fixed? How many core developers are present? Any fallback plans, ...? How to help to get there?
That's what I meant, it's always risky to rely on a single person for such an important subsystem as storage... I'm also very sad that bcachefs has been kicked out of the kernel, it is really a very promising FS.
So that leaves btrfs which always seemed complex and brittle to me (compared to zfs at least)
Depending on your current setup, dRaid can give you quite the performance boost nowadays, since its data slabs are spread out over all disks in the array its using all of the disks bandwith combined.
The script[1] shows it's a ZFS mirror (RAID-1) with 8k max record size, as opposed to the default 128k.
I say max, as ZFS stores multiples of the physical block size up to the record size. So even with 128k record size, if your file fits in two physical blocks, it will write two physical blocks of data.
The `ashift` parameter[2] controls the physical block size, typically 512 bytes or 4k for HDDs. Though higher can be useful on SSDs (but less tested, have seen some bug reports with >4k block sizes).
Typically you'd only want to use such small records if you are tuning it for a specific workload, like if you have a database that writes 8k pages.
Compression acts on records, so by limiting the record size, you limit the effectiveness of the compression: 1.2 and 1.8 blocks worth of data both gets written as 2 physical blocks.
On the upside, record size is a dataset property, so you can have many different datasets with different record sizes on the same pool.
reply