Does the Linux kernel avoid duplicate caching with compressing or encrypting filesystems? If so how?

Question

Out of curiosity: if I have a LUKS device according to my understanding when reading a block from a block device this block is put in the buffer cache. But this block is encrypted, so not immediately usable. When accessing the block it will be decrypted, so there is a second version of the data. This second copy would make more sense to cache than the disk block. I imagine the Linux kernel would reasonably cache this second block as well (coming from the loop device) - or even only this transformed block.

There is a similar situation with compressing filesystems like btrfs: a block read from disk is basically useless, only after decompression there is content that applications can use and which would make sense to cache.

I tried to find this information elsewhere (https://kernelnewbies.org, https://www.kernel.org/) but so far have not succeeded. What I found mostly covered older kernel versions and file systems that do not have this property of disk blocks that need to undergo a transformation to be usable. I would be thankful for some pointers.

Answer 1

I would be thankful for some pointers

I'd try looking at the output from free before and after first decrypting (cryptsetup [luksOpen | open --type luks]) mounting and reading from a LUKS device.

If the [ free | buff/cache | available ] spaces changes by about the size you've read, then it's only caching one copy. If the space changes by about double, it's probably caching two/both copies.

For security, I'd imagine / hope that the decrypted LUKS data is not cached. Usually the reading is slower than decrypting anyway.

• For testing, you could try creating your own (10x) encrypted LUKS device, using a few (hundred?) MB file and repeatedly luksFormat and luksOpen it, so it's using repetitive / nested encryption. Then any reads should be multiplied (10x) and that could be easier to see in free's output.