On Thu, Feb 20, 2025 at 02:48:21PM -0500, gene heskett wrote: > > On 2/20/25 14:10, Marco Möller wrote: > > To my understanding, it makes no sense to perform a TRIM on storage > > which is a LUKS2 encyrypted LVM. The storage device should anyway think > > that each bit is in use after it was filled with random data when > > creating the space. Not only that I cannot imagine how the storage > > device should Know what is happening in the encrypted space, wouldn't it > > be a security issue if the OS would inform the storage device about > > unused space and its location and could actually perform some kind of a > > TRIM? > > > > Am I wrong? > Yes. Generally speaking, all file systems know exactly whats in use, they > have to, otherwise they would randomly overwrite another file [...]
You are wrong here, Gene -- in a strangely indirect way. > encryption is only for the data in that allocated space. The file system > knows nothing about that data This is wrong when you have an encrypted block device, as is the case with LUKS. There, the file system sits "in" or "on top" of that block device and has no say on the en- and decryption steps. That means, of course, somewhat more inefficiency, but you are already paying quite a bit of that to keep privacy. The upside is that an external observer (even a malicious hard disk) don't get even to "see" which blocks have any data in them). Some day you should get a long sit down and try to pry those layers (block device, file system, etc.) apart. It's worth it. This is, of course, different, if you have file-level encryption. This would sit "on top" of the file system (ISTR Ubuntu "sold" that for a while). But why go with plastic calipers if you can get hold of metal ones? Cheers -- t
signature.asc
Description: PGP signature
