Originally posted by intelfx
View Post
Why is this even a counterargument to the "btrfs is not a meme" statement, how does absence of "extent v2" (assuming extent tree v2) makes btrfs "a meme"?
They did implement some optional trees as an optimization technique (free space, block group), but in the meantime XFS gained refcount btrees and so the reflinks, reducing need for btrfs-likes in certain scenarios.
In btrfs, advanced defragmentation and deduplication algorithms are supposed to be implemented in userspace.
[no reliable quota] From which ass did you pull this?
From public discussions on linux-btrfs@, provoked by issues spotted in production.
That can easily be reproduced, so just go ahead and share your results, before you throw insults next time.
I can trash entire volume in a matter of hours, therefore I choose carefully which volumes might be handled and can benefit from btrfs according to usage-patterns and needs, but none of them is exposed publicly or in Internet-facing services.
This supports my claim about not being general-purpose fs, as I don't have to think about any of my EXT4/XFS servers in the wild. Oh, I still got one reiserfs server waiting to be replaced.
[missing encryption, checksum-awareness in regard to RAID1]
What does this even mean?
What does this even mean?
It means you're not using filesystems extensively enough to understand trivia.
But let me explain: checksummed-filesystem-level RAID1 has an advantage, that when discrepancy in data is found, it can automatically read the other copy.
Without encryption baked into filesystem, one has to encrypt all the data twice (or more - one time per each mirror) and put already encrypted volumes into btrfs RAID1.
Considering that crypto-authentication is checksumming itself, this is both redundant and inefficient.
Assuming we want to encrypt only once and still fail over detected errors, this is more performant:
dm-integrity - RAID1+ - dm-crypt - fs (whatever, can be one-way btrfs, can be ext3).
but other issues emerge, namely initialization of empty space (that needs to be encrypted) or support for discard. Both of them are relevant if the stack lays on top of thinly provisioned device, e.g.
LVM-thin -> integritysetup -> mdadm -> LUKS -> fs
because now we're basically wasting space, unless we enable discards (not enabled by default at LUKS, security considerations).
But if we do TRIM and already have thin snapshots, this stack simply outperforms btrfs.
I do have some btrfs RAID1 over LUKS and this is PITA - I have to unlock all the components separately, before partially-activated btrfs goes into degraded mode.
In headless machines this is simply not reliable enough to be production ready.
This is why it's important to have encryption layer above RAID above checksumming.
This is why bcachefs providing encryption is such a deal.
Some stats from my fresh server, having clean setup (no legacy volumes):
Code:
$ lsblk | grep btrfs | wc -l 4 $ lsblk | grep xfs | wc -l 2 $ lsblk | grep ext4 | wc -l 25 $ lsblk | grep lvm | wc -l 139 $ lsblk | grep crypt | wc -l 32 $ lsblk | grep raid1 | wc -l 22
And let's not forget - comparing to btrfs which lacks per-subvolume profiles, the more similar setup is also much simpler one:
integrity -> RAID1 -> LVM -> LUKS or
integrity -> RAID1 -> LUKS -> LVM (if everything is to be encrypted and can use common key).
If the bcachefs was ready today, having reflinks, encryption, multidevice, checksumming, CoW and snapshots - it covers 95% of my needs.
The remaining are send/receive, which eventually will happen.
Leave a comment: