From: charlesfdotz@tutanota.com
To: Cryptsetup <cryptsetup@lists.linux.dev>
Subject: Feature Request: "Fake Trim"
Date: Thu, 5 Oct 2023 04:05:27 +0200 (CEST) [thread overview]
Message-ID: <Nfx_Hmi--3-9@tutanota.com> (raw)
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 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.
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 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.
Sincerely,
Chuck
p.s. I figure most of you already know why SMR drives don't play nicely with encrypted volumes so I glossed over it but I can elaborate if you'd like. Thank you.
next reply other threads:[~2023-10-05 2:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 2:05 charlesfdotz [this message]
2023-10-05 9:12 ` Feature Request: "Fake Trim" Yoann Congal
2023-10-05 11:19 ` Milan Broz
2023-10-07 23:03 ` charlesfdotz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Nfx_Hmi--3-9@tutanota.com \
--to=charlesfdotz@tutanota.com \
--cc=cryptsetup@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox