The reasons for using btrfs instead of lvm can be found here:
opened 09:46AM - 22 Mar 21 UTC
T: enhancement
P: default
C: storage
**The problem you're addressing (if any)**
In R4.0, the default install uses … LVM thin pools. However, LVM appears to be optimized for servers, which results in several shortcomings:
- Space exhaustion is handled poorly, requiring manual recovery. This recovery may sometimes fail.
- It is not possible to shrink a thin pool.
- Thin pools slow down system startup and shutdown.
Additionally, LVM thin pools do not support checksums. This can be achieved via dm-integrity, but that does not support TRIM.
**Describe the solution you'd like**
I propose that R4.3 use BTRFS+reflinks by default. This is a proposal ― it is by no means finalized.
**Where is the value to a user, and who might that user be?**
BTRFS has checksums by default, and has full support for TRIM. It is also possible to shrink a BTRFS pool without a full backup+restore. BTRFS does not slow down system startup and shutdown, and does not corrupt data if metadata space is exhausted.
When combined with LUKS, BTRFS checksumming provides authentication: it is not possible to tamper with the on-disk data (except by rolling back to a previous version) without invalidating the checksum. Therefore, this is a first step towards untrusted storage domains. Furthermore, BTRFS is the default in Fedora 33 and openSUSE.
Finally, with BTRFS, VM images are just ordinary disk files, and the storage pool the same as the dom0 filesystem. This means that issues like #6297 are impossible.
**Describe alternatives you've considered**
None that are currently practical. bcachefs and ZFS are long-term potential alternatives, but the latter would need to be distributed as source and the former is not production-ready yet.
**Additional context**
I have had to recover manually from LVM thin pool problems (failure to activate, IIRC) on more than one occasion. Additionally, the only supported interface to LVM is the CLI, which is rather clumsy. The LVM pool requires nearly twice the amount of code as the BTRFS pool, for example.
**Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted**
`man lvm`
**Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues**
#5053
#6297
#6184
#3244 (really a kernel bug)
#5826
#3230 ― since reflink files are ordinary disk files we could just rename them without needing a copy
#3964
everything in https://github.com/QubesOS/qubes-issues/search?q=lvm+thin+pool&state=open&type=issues
Most recent benchmarks: https://github.com/QubesOS/qubes-issues/issues/6476#issuecomment-1689640103
Also btrfs is now default filesystem in Fedora instead of lvm:https://fedoraproject.org/wiki/Changes/BtrfsByDefault
But you can use this guide and change btrfs to lvm as well.
It’s to achieve deniable encryption:
In cryptography and steganography, plausibly deniable encryption describes encryption techniques where the existence of an encrypted file or message is deniable in the sense that an adversary cannot prove that the plaintext data exists.
The users may convincingly deny that a given piece of data is encrypted, or that they are able to decrypt a given piece of encrypted data, or that some specific encrypted data exists. Such denials may or may not be genuine. For example, it may be impossible to pr...
Without USB stick the disk will look like unused/empty unpartitioned disk.
You mean why use swap at all or why swap file instead of separate partition?
opened 09:27AM - 05 May 24 UTC
RFE 🎁
cryptsetup
### Component
systemd-cryptsetup
### Is your feature request related to a prob… lem? Please describe
I want to configure deniable encryption for my system, for this I want to configure rootfs and swap on the same unpartitioned disk.
But for this I need systemd-cryptsetup to support `--shared` and `--device-size` (or `--size`) plain dm-crypt options:
>
> --shared
> Creates an additional mapping for one common ciphertext device. Arbitrary mappings are supported. This option is only relevant for the open --type plain action. Use --offset, --size and --skip to specify the mapped area.
>
> --size, -b <number of 512 byte sectors>
> Set the size of the device in sectors of 512 bytes. This option is only relevant for the open and resize actions.
>
> --device-size size[units]
> Instead of real device size, use specified value.
> With reencrypt action it means that only specified area (from the start of the device to the specified size) will be reencrypted.
> With resize action it sets new size of the device.
> If no unit suffix is specified, the size is in bytes.
> Unit suffix can be S for 512 byte sectors, K/M/G/T (or KiB,MiB,GiB,TiB) for units with 1024 base or KB/MB/GB/TB for 1000 base (SI scale).
Here is an example configuration that I'd like to use.
Rootfs encryption with detached header and offset for swap:
```
cryptsetup luksFormat /dev/sda -c aes-xts-plain64 -h sha512 -s 512 -y -i 10000 -o $((4*1024*1024*1024/512)) --use-random --force-password --header header.img
```
/etc/fstab
```
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / btrfs subvol=root,x-systemd.device-timeout=0,discard 0 0
/dev/mapper/swap none swap defaults,discard=once,x-systemd.device-timeout=0 0 0
```
/etc/crypttab
```
luks /dev/sda none force,discard,header=/root/header.img
swap /dev/sda /dev/urandom swap,discard,cipher=aes-xts-plain64,size=512,shared,device-size=4G
```
But for this I need to have `shared` and `device-size` plain dm-crypt options.
It it possible to add them to systemd-cryptsetup?
### Describe the solution you'd like
Add support for `--shared` and `--device-size` (or `--size`) plain dm-crypt options to systemd-cryptsetup.
### Describe alternatives you've considered
_No response_
### The systemd version you checked that didn't have the feature you are asking for
_No response_
Can you describe your question in more details? I didn’t get it.
robertford:
Usually it is not possible to umount /boot during runtime of the OS. But it looks like your setups unmounts /boot after startup and the user can detach the usb stick - which could be considered a security feature. At least you are writing that the user has to reattach the usb stick and /boot if one wants to update kernel, modules and initramfs.
You can safely unmount the /boot during runtime, the USB stick is only needed to boot the initramfs, you can remove the USB stick after you enter the disk password and dom0 will start to boot.
2 Likes