Meet Linux's Newest File-System: Bcachefs
An anonymous reader writes: Bcachefs is a new open-source file-system derived from the bcache Linux kernel block layer cache. Bcachefs was announced by Kent Overstreet, the lead Bcache author. Bcachefs hopes to provide performance like XFS/EXT4 while having features similar to Btrfs and ZFS. The bachefs on-disk format hasn't yet been finalized and the code isn't yet ready for the Linux kernel. That said, initial performance results are okay and "It probably won't eat your data — but no promises." Features so far for Bcachefs are support for multiple devices, built-in caching/tiering, CRC32C checksumming, and Zlib transparent compression. Support for snapshots is to be worked on.
If there's a Mrs Overstreet, she needs to be careful. Linux FS programmers have a bit of a history.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Just what we needed!
Said no one ever.
Is this the Linux answer to swapcache and the HAMMER filesystem in DragonFly BSD? Of course, a major generalization and oversimplification, but it seems a similar kind of approach to a similar set of problems.
# make clean sig
> a modern COW filesystem with checksumming, compression, multiple devices, caching, and eventually snapshots and all kinds of other nifty features
Instead of yet another FS flavor of the month, or year, (Reiserfs, Btrfs, Bcachefs, etc.) and all the man-hours wasted re-solving the same old problems how about just doing it right the first time (ZFS) ?? Because this is what it is turning into. What advantages bachefs have over ZFS??? There is no way in hell I'm going to trust an unproven, buggy, and incomplete FS when we already have one that works.
Fixing the Butr free space shenanigans would have been a step in the right direction: An existing debugged FS.
Reminds me of this xkcd #927: Standards
Maybe your goals aren't shared by anyone that actually writes the OS or applications for Linux. Who cares what windows twats do?
You are all cows, which get butchered, cooked by bca-chefs and served by Xerox! Cows say mooo. MOOOO! MOOO Cows MOOO! Mooo say the Cows. YOU COWS!!!!
:P
And this is why Linux will never replace Windows
I like the idea this filesystem is going for... it can be useful as a cache, so that hardcore random I/O is smoothed out before it goes onto HDD platters, so a SSD can function as a place for the OS, and as a cache between a drive array or slow external drives.
My only addition would be encryption. If it is designed to work as a transient, ephemeral filesystem where data is only kept until it is safely copied to the real filesystem, then maybe encryption should be a part of this, with keys for data periodically changed out to ensure that data already written to the HDD is not going to be recovered, or if the cache is used as a read cache, the key would reside in RAM and the cache rebuilt on reboot.
Has better durability, semantics, and outperforms ext4 in most tests and even tmpfs in a few.
Eagerly awaiting mainline merge--waiting for mostly politics to resolve, or so it seems.
From Mr. Overstreet's announcement:
PSA: Right now I'm not getting any kind of funding for working on bcachefs; I'm :)
working on it full time for now but that's only going to last as long as my
interest and my savings account hold out. So - this would be a wonderful time
both for other developers to jump in and get involved, and for potential users
to pony up some funding. If you think this is interesting and worthwhile and you
want to see it completed and upstream - especially if you're at a company that
might make use of it - talk to your $manager or whoever and nag them until they
send me a check
Omne ignotum pro magnifico.
So what? It doesn't need to.
Linux is a free market of ideas and devotion. Projects that are interesting or useful tend to attract developers who are willing to contribute to the project. Those that are unnecessary or niche tend to languish or serve an obscure base of users. Regardless of where along that spectrum any project falls, we're all collectively richer through no effort of our own and at no cost beyond learning to use the software.
If the ability to create your own solution or choose from among many doesn't interest you, you don't have to use it. Air hockey is unlikely to replace football, but that doesn't mean you still can't enjoy it if it's to your tastes.
One whole hell of a lot more people than care what Linux twats do.
CRC32C and zlib? What year is it?
Seriously, why? Compression is only fun when it is so fast it increases (as opposed to decreases) performance. LZ4 in ZFS style. Maybe someone can speak to the merits of CRC32C, but I never actually expected to see CRC32 used in new software again.
Strange, on Earth the internet is not powered by windows servers but rather Linux and BSD ones, nor are smart phones running windows but BSD and Linux. What planet do you live on? The planet of the twats?
who gives a shit? only twats like you apparently
"It probably won't eat your data — but no promises."
Well, that's a ringing endorsement if I ever heard one. Thanks but no thanks.
Just cruising through this digital world at 33 1/3 rpm...
I guess writing a new filesystem is easier than fixing the existing bugs in bcache itself.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Sure, I can understand why, if you're building a ZFS server with tens of terabytes of disk and tens of GB of RAM, you can dedicate an SSD to accelerating it. But more commonly, I'm using a laptop or older desktop that doesn't really have enough horsepower to do that, and may not have room for both an SSD and a spinning disk, and I'd like to just throw a random USB stick on their to use for caching. Windows had something like that for a while (never really helped much, and now that my work laptop has an SSD it doesn't use it at all), but is there some way to accelerate my boring desk-side lab box at work by plugging in a 4-8GB flash stick? Or to accelerate the wimpy server we're using for OpenStack?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Seriously, no 'file manager' solution I've seen so far works adequately, and in a way that preserves such tags across devices / disks / etc. What do other slashdotters do for tagging purposes?
I'd be suspicious of anyone using the actual term 'pony up' on a kernel mailing list.
Unless of course, it's a development list [ANNOUCEMENT] by Pony-OS
developers,working on code for production ready Pony-OS deployments,
who have commit access to the upstream Pony-OS git repository and
are in the process of pushing an new Pony-OS major release.
But even in that case, they'd still be better off using XFS.
Serious question:
Is there a reliable Linux file system such as EXT4 that has an easy to use copy on write(CoW) feature to allow instant recovery of any file changed at any time?
rm ./test ./
restore --last test
dd if=/dev/random of=./test bs=1M count=10 ./
restore --datetime test
Novell Netware FS did all this and more in 1995 FFS! Fifteen years later and Linux doesn't seem to be able to do this. NTFS doesn't seem to be able to do this either. Yet Novell is dead?
s/their/there/
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks