Btrfs With Linux 5.12 Gets More Performance Improvements, Working Zoned Mode

[cynic]

Hearing about BTRFS "improvements" while on a BTRFS filesystem scares the shit out of me.

Guess I'll have to do my backups and skip 5.12 for a few months until other people are offered as "human sacrifice" to test if it is a totally clusterfuck or not.

so, what about ext4 or XFS improvements?
If you're so scared about technology progress you should use an enterprise distro and stuck with its default kernel.

[ElectricPrism]

Hearing about BTRFS "improvements" while on a BTRFS filesystem scares the shit out of me.

Guess I'll have to do my backups and skip 5.12 for a few months until other people are offered as "human sacrifice" to test if it is a totally clusterfuck or not.

[WorBlux]

Question for those more familiar with disk/file encryption.

Filesystem aside, one can have full disk encryption and file/directory encryption (filesystem agnostic), and then there is filesystem specific encryption? (which BTRFS lacks)

In what scenario is it useful to have filesystem encryption when you have the other two?:

• encrypted disk at rest offline(as in not actively booted/unlocked) - Usually uses AES-XTS which iirc has some negatives, but is due to context of content/input to encrypt/decrypt.
• files protected at rest during runtime (as in you're logged into a session and can unlock/decrypt a vault or w/e of encrypted data, but it's otherwise protected from third-parties that can access the system while it's running) - Can support nicer ciphers like AES-GCM

I assume it's perhaps something you'd want if you're not using/trusting full disk encryption (which I recall some vendors having flawed implementations for that ended up not providing protection as well as assumed?).

I believe I have seen mention of using LVM with LUKS to work around BTRFS lack of filesystem level encryption, but that there are gotchas/drawbacks mixing LVM with BTRFS. Just curious how useful such a feature is at the filesystem level.

The main one is you can do certain maintenance operations (resize, scrub, send/recieve) without exposing file metadata.

[polarathene]

Question for those more familiar with disk/file encryption.

Filesystem aside, one can have full disk encryption and file/directory encryption (filesystem agnostic), and then there is filesystem specific encryption? (which BTRFS lacks)

In what scenario is it useful to have filesystem encryption when you have the other two?:

• encrypted disk at rest offline(as in not actively booted/unlocked) - Usually uses AES-XTS which iirc has some negatives, but is due to context of content/input to encrypt/decrypt.
• files protected at rest during runtime (as in you're logged into a session and can unlock/decrypt a vault or w/e of encrypted data, but it's otherwise protected from third-parties that can access the system while it's running) - Can support nicer ciphers like AES-GCM

I assume it's perhaps something you'd want if you're not using/trusting full disk encryption (which I recall some vendors having flawed implementations for that ended up not providing protection as well as assumed?).

I believe I have seen mention of using LVM with LUKS to work around BTRFS lack of filesystem level encryption, but that there are gotchas/drawbacks mixing LVM with BTRFS. Just curious how useful such a feature is at the filesystem level.

[phoronix]

Phoronix: Btrfs With Linux 5.12 Gets More Performance Improvements, Working Zoned Mode

David Sterba on Tuesday submitted the Btrfs file-system updates for the Linux 5.12 kernel, which once again include more performance optimizations and notable new features...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.12-Btrfs