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

[S.Pam]

I don’t think so. IIRC this is largely targeting enterprise drives / data centres

It would be great if consumer SMR drives did.

[Markopolo]

Do any consumer drives support zones exposed to users?

I don’t think so. IIRC this is largely targeting enterprise drives / data centres

[S.Pam]

Do any consumer drives support zones exposed to users?

[waxhead]

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.

There are bugs in every software. How often and how easy those bugs bite is far more important. For example if you hit a bug only if your filesystem is over 500 terrabytes it is not something the majority of users would be too much concerned about. Same thing about disk arrays >32 disks.

You should always have tested backups of valuable data you care about anyway.

On the other hand... BTRFS have saved me from disaster and corruption more than once. I have been using it since before 2013 and have never lost anything. There was a nasty bug in early kernel 5.2 that hit me. However I was able to recover everything without much problems. Other non-check-summing filesystems may not complain about corruption so you never know if you data is sane in the first place and when you notice a 'blipp' in your movie/audio/picture or whatever you would know if your files has been corrupted locally or not.

BTRFS have (for me) worked flawlessly on stable LTS kernels and as long as you only use the stable features you should be better off than with just about any other filesystem. Most horror stories on the mailing list is usually due to some exotic set up, bad hardware, usb drives or old (usually non LTS) kernels.

[darkbasic]

sub-page block size support is now working but with more work still on the way

Wow, does it mean that I will finally be able to mount a ppc64le (64K page size) btrfs partition on x86_64?

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

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

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

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

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