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

[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?pag...nux-5.12-Btrfs

[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.

[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.

[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.

[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.

[oleid]

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.

You don't need LVM when you have btrfs. It is just the distribution installers which can't do better. I'm using an encrypted drive partition (LUKS) and btrfs directly on top of that. The distribution is installed to its own subvolume (@archlinux) and the user data lives in another sub volume (@homes). Things are zstd compressed (lvl 3) by default in my setup.

Such a setup is Boot-able with grub (it should even work to store the initramfs in btrfs) or if you store the initramfs outside the encrypted partition with anything else.

[DanglingPointer]

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.

I've had this for 6-7 years no problem!...

• OS on EXT4 over full disk encryption (from ubuntu installer). Decrypted on boot using password just after grub.
• 7 disks each Luks encrypted by keyfile stored in privileged location in encrypted OS disk path (first point above), once again only accessible via password input after grub
• BTRFS RAID5 on top of all the 7 disks. (yes yes to the anxious types, I live on the edge and have been with two servers for the past 6 and half years with no problems!).
• quarterly scrubs via cron

Has not failed me yet! Even with dead disks or disk replacements, BTRFS RAID5 has worked for more than half a decade for me!

[polarathene]

• OS on EXT4 over full disk encryption (from ubuntu installer). Decrypted on boot using password just after grub.

Thanks for sharing that (and everyone else who responded).

Why is you OS disk EXT4 instead of BTRFS? Is it due to some part of the process not being compatible with BTRFS?

Your 7 BTRFS disks use encryption from LUKS but not full disk encryption like EXT4? (it seems that I might have been mistaken here, when I said full disk encryption I was referring to hardware disk encryption, a feature a disk vendor provides, instead of FDE it's apparently called SED: Self-Encrypting Drive)

[curfew]

Your 7 BTRFS disks use encryption from LUKS but not full disk encryption like EXT4? (it seems that I might have been mistaken here, when I said full disk encryption I was referring to hardware disk encryption, a feature a disk vendor provides, instead of FDE it's apparently called SED: Self-Encrypting Drive)

That feature has got nothing to do with any filesystem, not Ext4 and not BTRFS.

Full disk encryption means a scheme where there is no "visible" partition layout (nor partitions nor data), only a single encrypted container, which has to be unlocked first and then can be exposed as a common block device with partitions and data contained inside. This is what we can have with LUKS and is possible to combine with BTRFS or Ext4 or anything else. (In practise UEFI/Linux boot partitions must still remain unencrypted.)

More advanced scheme is to have the filesystem itself use encryption which is more flexible than the aforementioned scheme. Here I am not entirely sure about the details. Anyways this is what Ext4 currently supports among others but BTRFS doesn't.

[DanglingPointer]

Thanks for sharing that (and everyone else who responded).

Why is you OS disk EXT4 instead of BTRFS? Is it due to some part of the process not being compatible with BTRFS?

Your 7 BTRFS disks use encryption from LUKS but not full disk encryption like EXT4? (it seems that I might have been mistaken here, when I said full disk encryption I was referring to hardware disk encryption, a feature a disk vendor provides, instead of FDE it's apparently called SED: Self-Encrypting Drive)

Luks is capable of full disk encryption. Partitioning is done on top of it. That's what I did for each disk. Btrfs stripes are done on top of the luks.

The Ubuntu installer uses luks for full disk encryption. EXT4 is done on top of luks.