Earlier quoted context omitted.
when the RAID is handled by a different layer you lose some very important integrity features
IIRC, doesn't BTRFS also allow you to do cool things like change RAID levels dynamically? (E.g. You can be running a 2-disk RAID-1 array, pop in another disk and tell BTRFS to make it a RAID-5 array instead, then a year later pop in 2 more disks and switch to RAID6, all with no downtime.) I imagine that wouldn't be possible if you were doing RAID at a different layer.
Bcachefs: “the COW filesystem for Linux that won't eat your data”
51–60 of 110 posts
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#52Earlier quoted context omitted.
when the RAID is handled by a different layer you lose some very important integrity features
That's why all big data in big corporations uses exotic-open-source-filesystem-based RAID. That's where the action is when it comes to integrity. None of that virtual block device or driver-level software junk, let alone hardware RAID controller solutions.
That isn't to say that using high performance block storage isn't still a win even when the redundancy is multiplied at a higher level. The higher level redundancy is also about colocating more data with the code - i.e. it's not just redundant for integrity, but to increase the probability it's close to the code.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#53It looks like it takes quite some time till it is fully implemented. Why should we start using it right now instead of btrfs/zfs?
You probably shouldn't. It's ready for adventurous testers, and is pretty stable, but unless you're willing to report bugs or hack on it, you can probably stay away. There are reasons to still want it, despite its newness; for example, the latest updates bring huge improvements in metadata efficiency (low metadata overhead -> more metadata in the cache -> larger working set). Someone on the IRC channel reported it's…
https://gist.github.com/liloman/d525131fab9b9a440140905921e9...
I'll give it a try on bcachefs. :)
The script needs a 512MB spare disk partition and some basic changes but the fundamental work is there.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#54If you think we need an alternate effort and/or competition to build an advanced, native filesystem for Linux (I do), please consider a subscription on Patreon (https://www.patreon.com/bcachefs). Kent has a long history of shipping sophisticated, high-quality code.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#55To press this point: If you think we need an alternate effort and/or competition to build an advanced, native filesystem for Linux (I do), please consider a subscription on Patreon ( https://www.patreon.com/bcachefs ). Kent has a long history of shipping sophisticated, high-quality code.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#56I've been using btrfs since about 2011, and I've stopped using ext4 / xfs / zfs everwhere since about 2014. From 2012-2014 it was mostly breakage every other month. From 2014-2016, it was semi-annual issues. For the last ~18 months I have had ~30 machines running btrfs with no issues, some servers, some personal computers. The release notes are boring, the bugs are boring, and to me its definitely in a state I would…
I've been using btrfs since about 2014 on CentOS7. I only use it with mirroring+compression. No snapshots. I mostly went with it for data scrubbing and compression. My experience has been mixed, but haven't had any data loss. There was a bug for a while regarding free space so occasionally the system would seem to be full but wasn't ....and it was a real pain to correct it. I now have a cron job that does a monthly b…
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#57I've been using btrfs since about 2011, and I've stopped using ext4 / xfs / zfs everwhere since about 2014. From 2012-2014 it was mostly breakage every other month. From 2014-2016, it was semi-annual issues. For the last ~18 months I have had ~30 machines running btrfs with no issues, some servers, some personal computers. The release notes are boring, the bugs are boring, and to me its definitely in a state I would…
I moved back to EXT4 and it never happened again since then.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#58Apparently they were not aware of the fact that bcache was a) GPLd code, or b) developed before the company existed, first as a hobby project and then at Google. After a couple of years, they noticed that Kent was in fact posting the bcache source code on his personal web site. At this point they fired him and threatened to sue. I quit the company then (along with a number of other people, for mostly unrelated reasons, such as the fact that the CTO was a notorious brogrammer). Kent got a litigator and when it was made very clear to them that they had no case, they backed down, but not before wasting a ton of money.
As far as I know, they're still actively violating the GPL by shipping a product containing modified kernel code in it without releasing the source, nor do they acknowledge that they did not develop the key component of their product.
The "commercial" version had a rather broken and messy snapshots implementation and had diverged a bit from the open source bcachefs at that point, mostly because snapshots were poorly implemented. It's also kind of funny because after we left the company we still knew of some tricky data corruption bugs, and it's likely they're still there in the "commercial" version, because backporting the latest fixes would be non-trivial and I don't think their testing or development methodology would have caught them.
Anyway, I gave up on startups and enterprise storage after this, but Kent is still developing bcachefs on his own time and money, so if you use it please consider donating some money to support its development.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#59Earlier quoted context omitted.
Me too. I love it, but only with raid-1 or no raid. btrfs as a filesystem will be dead within the next 12 months unless they fix raid-5 and raid-6.
I'm using BTRFS on many VMs running Ubuntu servers, and I find that expanding the virtual hard-disk, on Proxmox, without stooping the VM it's far trivial.
Re: Bcachefs: “the COW filesystem for Linux that won't eat your data”
#60Earlier quoted context omitted.
I've been using btrfs since about 2014 on CentOS7. I only use it with mirroring+compression. No snapshots. I mostly went with it for data scrubbing and compression. My experience has been mixed, but haven't had any data loss. There was a bug for a while regarding free space so occasionally the system would seem to be full but wasn't ....and it was a real pain to correct it. I now have a cron job that does a monthly b…
ZFS gets you all of that and raid and snapshots and has been tested time and time again. Why run BRTFS then?