More Bcachefs Fixes Land In Linux 6.7

[phoronix]

Phoronix: More Bcachefs Fixes Land In Linux 6.7

Of the many new features in Linux 6.7, one of the items exciting Phoronix readers the most is the merging of the long-in-development Bcachefs file-system...

https://www.phoronix.com/news/Bcachefs-More-Linux-6.7-Fixes

[blackiwid]

For what people here seen it as the much better than btrfs thing, it seems to lack more features and stability. Maybe it will be great in kernel it should at least become descent, but as the big btrfs killer people claimed it would be I can't see it soon.

[Quackdoc]

For what people here seen it as the much better than btrfs thing, it seems to lack more features and stability. Maybe it will be great in kernel it should at least become descent, but as the big btrfs killer people claimed it would be I can't see it soon.

I mean, as long as it doesn't eat my data, it will already be a singificantly better alternative to btrfs

[waxhead]

I mean, as long as it doesn't eat my data, it will already be a singificantly better alternative to btrfs

Let me challenge you on this. Show me ONE example the last 5 years where people have lost their files on a BTRFS setup with more than two storage devices, Raid1/10 for both data and metadata, and not having BTRFS on top of LVM / Luks / any other layer (such as bcache)..

[AlanTuring69]

Let me challenge you on this. Show me ONE example the last 5 years where people have lost their files on a BTRFS setup with more than two storage devices, Raid1/10 for both data and metadata, and not having BTRFS on top of LVM / Luks / any other layer (such as bcache)..

While it is true that btrfs has gotten much much much better, not encrypting your data at rest is insane and disk encryption is one of the most basic security/privacy precautions anyone can take. It obviously doesn't save you from yourself but it does save you from physical theft which is increasingly an issue especially as thieves get more tech savvy. Btrfs lacking native encryption support is a gigantic feature gap because, as you implied, it is another layer on top of a complex filesystem which can introduce unpredictable issues or performance penalties. Bcachefs seems to understand the importance of this and I hope their execution turns out well... or ZFS gets mainlined somehow.

Every phone sold today is encrypted by default along with macOS, Windows makes it very easy and you'll find almost every cloud instance in a public cloud is backed by encrypted storage. These days it's essential and if you're using Btrfs, a checksummed filesystem with not-strictly-the-best performance, you probably care about that data.

[Mitch]

While it is true that btrfs has gotten much much much better, not encrypting your data at rest is insane and disk encryption is one of the most basic security/privacy precautions anyone can take. It obviously doesn't save you from yourself but it does save you from physical theft which is increasingly an issue especially as thieves get more tech savvy. Btrfs lacking native encryption support is a gigantic feature gap because, as you implied, it is another layer on top of a complex filesystem which can introduce unpredictable issues or performance penalties. Bcachefs seems to understand the importance of this and I hope their execution turns out well... or ZFS gets mainlined somehow.

Every phone sold today is encrypted by default along with macOS, Windows makes it very easy and you'll find almost every cloud instance in a public cloud is backed by encrypted storage. These days it's essential and if you're using Btrfs, a checksummed filesystem with not-strictly-the-best performance, you probably care about that data.

Encryption is a must have for my piece of mind surely. The dangers of someone grabbing session cookies and other private data is pretty real. It even happened to Linus Tech Tips' channel. That said, the fact that LUKs has pretty solid encryption does mean to me that Filesystems including it natively doesn't seem as high priority as otherwise. I'm not sure what BTRFS's priorities are, but I'd love for them to really nail down their Raid6. I've heard they made it much better than before, but it's still not super safe.
LZ4 support would also be pretty nice, though they were not interested supporting it as of some years ago. Maybe PCI NVME drives will tip the scales.

[billyswong]

Speaking of encryption support within filesystem layer, I think there are a bunch of tradeoff.

In past theory, a full disk encryption separate from filesystem can make a filesystem unrecognizable as drive with content and can claim to authority this is just a junk disk. But nowadays this is unlikely to work. And most full disk encryption applied to boot drive can't achieve that effect anyway.

A disk encryption scheme embedded into filesystem can reduce the chance of local IO/data corruption ruining the whole drive and losing all contents within. To most people, this resilience is desirable. For some paranoid or special need people, this maybe a disadvantage as it makes them harder to destroy what they stored in emergency.

[AlanTuring69]

Speaking of encryption support within filesystem layer, I think there are a bunch of tradeoff.

In past theory, a full disk encryption separate from filesystem can make a filesystem unrecognizable as drive with content and can claim to authority this is just a junk disk. But nowadays this is unlikely to work. And most full disk encryption applied to boot drive can't achieve that effect anyway.

A disk encryption scheme embedded into filesystem can reduce the chance of local IO/data corruption ruining the whole drive and losing all contents within. To most people, this resilience is desirable. For some paranoid or special need people, this maybe a disadvantage as it makes them harder to destroy what they stored in emergency.

I personally use LUKS+F2FS on my root NVMe partition and it works fantastic, but I wouldn't use it with a more complex filesystem like btrfs, zfs etc. I use an OpenZFS zpool for the big stuff (with native encryption of course...) which also works fantastic. If I was particularly masochistic I'd use ZFS on root... or install FreeBSD.

[linuxgeex]

Speaking of encryption support within filesystem layer, I think there are a bunch of tradeoff.

In past theory, a full disk encryption separate from filesystem can make a filesystem unrecognizable as drive with content and can claim to authority this is just a junk disk. But nowadays this is unlikely to work. And most full disk encryption applied to boot drive can't achieve that effect anyway.

A disk encryption scheme embedded into filesystem can reduce the chance of local IO/data corruption ruining the whole drive and losing all contents within. To most people, this resilience is desirable. For some paranoid or special need people, this maybe a disadvantage as it makes them harder to destroy what they stored in emergency.

You can't encrypt boot volumes other than via the BIOS, either with a password or TPM, but that is a bit of a pain for remote restart, at least without a BMC/KVM/IP setup.

You can sort-of encrypt the boot device by putting GRUB, kernel, and initrd onto a flash drive, and you can even put the LUKS header onto the flash drive (using LVM to concat a partition on the flash drive with the system drive such that the header is on the flash drive's partition) and then yank the flash drive after it boots. Then the boot drive looks like pure random noise, but only if you don't use TRIM-pass-through... and without that the drive's performance goes deep in the toilet.

So if you want plausible deniability for the drive contents, you need to accept that performance is going to suffer, and remote reboot will only work over a BMC/KVM/IP setup that allows supplying a remote USB boot image.

I had a laptop with GRUB unencrypted and LUKS for the kernel/initrd partition, so you had to provide a passphrase after selecting the boot option from GRUB. It got stolen in Jan 2018 from my gf's car while we were watching a movie. It was suspended to RAM.

When I found it missing I ran the backdoor self-destruct script on my chromebook. The laptop had a guest/honeypot account. Either the thieves logged it into WiFi via the honeypot account, or one of the many public WiFi AP's was in range after they woke it. The Tor daemon connected the ssh hidden service came up. The self-destruct script uses ssh to execute "sudo su -c 'cat /dev/zero /dev/nvme0n1p3;sleep 3; sync;reboot'" which erases the LUKS header from the system partition.

So even if they managed to get the passphrase the disk is effectively erased. The honeypot account also had backdoors, and redlist accounts, so that I'd know how far they got attempting to exploit it. They didn't try any. I suspect it was a public AP and an unsophisticated attacker. Which is a shame as I could have exfiltrated the data on the SD card... some holiday photos that were not backed up yet.

[Quackdoc]

Let me challenge you on this. Show me ONE example the last 5 years where people have lost their files on a BTRFS setup with more than two storage devices, Raid1/10 for both data and metadata, and not having BTRFS on top of LVM / Luks / any other layer (such as bcache)..

for a period of 8 months I tested btrfs across multiple devices ending 1 and a half years ago, of 17 storage devices 8 of them failed. 6 of the failures were unrecoverable. a lot of these were single drive devices.

1 failure was on a flash drive, 1 on HDD, 2 on emmc, and the rest on SSD. I tested an assortment of things from nocow VMs to scratch disks for video to image sequence stuff. btrfs to me has absolutely unacceptable reliability issues