vdo

> would want to have compression.. I learned about VDO today. [0][1] I'd never heard of it before, but I'm using Gentoo Linux and both the dm-vdo kernel module and the 'vdo' software provided by [1] are distributed by Gentoo... so this isn't some weirdo Red Hat thing. It looks like you manage and used these just like any other thin-provisioned LVM volume [2], but -like I said- I've not used this before, and have only just skimmed the docs, so it's possible that I'm missing something important. [0] <https://docs.redhat.com/en/documentation/red_hat_enterprise_...> [1] <https://github.com/dm-vdo/vdo> [2] <https://docs.redhat.com/en/documentation/red_hat_enterprise_...>

Don't use BTRFS! I still encounter crippling data loss and error messages in my dmesg log after giving it another shot for the last 10 months. I try btrfs with Arch Linux every few years because of its native transparent compression abilities. Enough is enough! Just say no. Friends don't let friends use btrfs. bcachefs is the only hope left for normal Linux users but it has not landed yet. I am using ZFS for /home (with zstd compression) on LVM on LUKS and my root partition is ext4 on LVM on LUKS. I considered VDO for LVM because it supports compression but VDO IS A JOKE! https://github.com/dm-vdo/vdo/issues/38

Isn't it solved by adding an abstraction layer between the storage and the filesystem, the way "vdo" ( https://github.com/dm-vdo/vdo ) does it?

> It exposes a virtual device backed by a real one, adding a layer of compression, am I reading it right? And deduplication, yes. >Can I grow the logical size later? Yes; the man page for the program discusses the growLogical subcommand briefly: https://github.com/dm-vdo/vdo/blob/6.1.1.24/vdo-manager/man/... >I can also see that we're specifying a "logical size" that is exposed to the user. How much space is really used and how is it allocated? There's a vdostats command mentioned in the article that exposes how much actual space is available and used. >Apart from this - what is the status of the patch, is it redhat-only or is it on its way to the upstream? It has not yet been submitted as a kernel patch.