Iβm always nervous when hearing about new filesystems since a certain high profile news incident a several years back.
I really, really, really hope that Kent Overstreet has a really good relationship with any partner or spouse he may or may not have.
Built-in encryption in bcachefs sounds great, thatβs the only thing that BTRFS has been missing for me so far.
Bonus points if it can be decrypted on boot like LUKS, and double bonus points if its scriptable like cryptsetup (retrieve key from hardware device, or network, or flash stick etc)
https://bcachefs.org/Encryption/
Will likely give bcachefs a spin as soon as it drops in Debian Unstable π
Yeppp this is what I currently do, and offers the best performance IMO compared to using something like gocryptfs in userspace on top of BTRFS. Pretty happy with it except a few small thingsβ¦
It can be a bit of a faff to mount on a new machine if its file manager doesnβt support encrypted volumes natively βΉοΈ. On your daily you can have it all sorted in your crypttab and fstab so itβs not an issue there
My main problem though is if itβs an external USB device you have encrypted with LUKS, the handles and devices stay there after an unexpected USB disconnectβ¦ so you canβt actually unmount or remount the dm-crypt device after that happens. Anytime you try, the kernel blocks you saying the device is busy - only fix iβm aware of is a reboot.
If the encryption is managed by the filesystem itself, one would probably assume this kind of mounting & unexpected disconnect scenario would be handled as gracefully as possible
I see, good points.
I have also experienced that dangling devices break remounting it, but I think thereβs a quicker solution for it: dmsetup remove insert_device_name_here.
Itβs still a manual thing, though, but 2 steps better. Maybe it can be automated somehow, I havenβt looked into that yet.
Iβm a happy btrfs user, but itβs most definitely a great thing to see what seems like a really clean implementation like this that is able to learn from the many years of collective experience with ZFS and btrfs.
Iβm really excited for this. If it lives up to the hype I think it could become the defacto filesystem some day.
BTRFS, despite being a great filesystem, got a bad rep mostly due to its poor RAID5/6 implementation. It also lags behind in performance in many configurations and has been mostly relagated to a specialty filesystem. While it could make a great root filesystem few distros have adopted it as such.
ZFS has been similarly pigeon holed. Itβs typically only used for building large arrays because itβs not very safe when used on a single device (edit: After some research this may not be true and is probably outdated or incorrect info stuck in my head) . It also lacks a lot of the flexibility of BTRFS, though you could say it trades flexibility for reliability.
bcachesfs on the other hand feels like it has the potential to be adopted as a root file system while also providing replication, erasure coding, high performance and snapshots; something that no filesystem has managed to date, at least on a wide scale.
Yeah. I only use it in Fedora because it was one of or the default partition scheme or the recommended one, canβt remember. But Iβm impressed with it, actually. Enough to make me try to learn the basics, in case I have to install another distro.
Fedora adopted it as default with Fedora 33. SUSE has been using it as default for many years now. Facebook is one of the largest users and contributors to btrfs. Itβs a solid filesystem when itβs not used to do things it warns you not to do.
Itβs not that I donβt trust it. Iβm sure some years ago it was the base of some distro in my laptop. The thing is Iβm more old school in terms of filesystems and partitions. I need to learn how to use it properly to enjoy its advantages.
Do you happen know if bchachefsβs raid5/6 implementation is working/stable?
I donβt believe itβs been marked stable yet but it doesnβt suffer from the raid write hole like BTRFS and claims to be more performant than ZFSβs implementation.
With it being merged into the kernel it should get much wider use and hopefully that helps it reach stability.
ZFS was pigeonholed? Thatβs news to me. Itβs used on datacenter storage solutions everywhere.
I was referring to its lack of use as a root filesystem. Itβs primarily used for large storage arrays both at home and in data centers.
Itβs not a great choice for everyday use, thatβs why. Itβs a fine solution for scaled storage that makes it more performant on large disk arrays though.
Honestly this is probably me going off of outdated or even incorrect information. The fact that it has little adoption for that use case or as a root filesystem is probably the larger factor.
Itβs been awesome to see Ubuntu embrace it over the last few releases though and thatβs certainly starting to change things but since itβs not part of the Linux kernel that gives most other distros pause I think.
The lack of adoption is more about nervousness around who created it more than anything. Itβs incredibly stable and very well tested.
Itβs a shame because openzfs is really truely fantastic, so hoping this new thing keeps that momentum but for a wider audience.
But sad to see people like yourself suggest myths around zfs that donβt have any basis, probably one of the other reasons itβs less used, people think there must be some reason and things get made up along the way
Good. For one thing, we can move on to drama about something else. But, also, Iβd like to play with it without having to build a kernel.
