Re: Feature Request: "Fake Trim"

[Milan Broz <gmazyland@gmail.com>]

On 10/5/23 04:05, charlesfdotz@tutanota.com wrote:
> Hello,
> 
> I would like to request a feature regarding luks volumes. I had
> wanted to post this to your gitlab but they want a credit card and
> phone number (?!) to sign up. I hope doing this via the mailing list
> is OK.

I am owner of cryptsetup project on GitLab and I never entered credit
card number (and we have GitLab for OpenSource Ultimate license there).
Email should be ok for registration, and many other people have account
- are you sure it really needs these data? If so, ask Gitlab why.
We do not need anything like that.

(Anyway, issue for cryptsetup is not the proper place anyway, dm-crypt
is kernel part, perhaps dm-devel@redhat.com list is better for kernel
feature discussion.)

> I would like to request that a new mount option be added for luks
> volumes that when enabled would allow the luks volume to accept trim
> requests regardless of the underlying hardware and then to simply
> write zeros to the sectors that are trimmed. This might seem like an
> odd request but there are a few situations where I think it would be
> useful.

IMO block layer is the proper place to emulate TRIM (so any block device
can do that). I do not think device-mapper should implement own
emulation. Not sure if it is a good idea, but if so, I would expect any block
device should be emulate TRIM (then LUKS can support it just by enabling
discard options).

Anyway, I think you are trying to fix hw problem in sw here...

> The first is that currently it is just not feasible using luks on top
> of an SMR drive if it doesn't support trim. Currently an SMR drive if
> left untrimmed while using an encrypted volume will have performance

So SMR drives should support TRIM if they really on it...

I am not going add any support for SMR "optimizations" to cryptsetup.
These crappy drives just should not exist :)

But seriously, if the drive has some special use (like long-time recording
- writing continuously stream of data) and you want to use it with
random write (and encrypted) access (data deduplication cannot be done
internally) you are screwed anyway. It will never work properly.

> falls off a cliff permanently after enough data is written to it. For
> drives with trim support this obviously isn't an issue but at first
> glance drives that do not support trim would seem to be worthless.
> Fortunately most drives that don't support trim are smart enough to
> "time" a sector if it gets filled with zeros (you can find several
> accounts of people "refreshing" their drives by simply dd'ing them
> from /dev/zero). Obviously you can't do that if there's a luks volume
> on the drive because it won't actually write zeros to the disk but if
> my "fake trim" request were implemented it would solve the issue.
> This would make proper encryption possible on a large subset of
> previously unusable drives.
> 
> The second situation is using a luks volume on a virtual machine
> disk. Often time the VM disk will either be compressed or a sparse
> file but if encrypted with luks once all the space has been written
> there is no way to reclaim space. I'm aware some virtual disks
> support "normal" trim but I believe this would still be useful in
> some cases.

I do not understand what is missing in the second case.

You can use thin provisioning, it uses TRIM exactly as you mentioned.

But loopback (/dev/loop) should support TRIM too, so reclaiming unused space
in file image is just to allow discards for LUKS device and issue fstrim
(or blkdiscard for the whole block device). This works for years.

Loopback is allocated automatically by cryptsetup, so all you need
is to add --allow-discards on open of file image.

Milan