Btrfs and KSM (kernel samepage merging)

Ask Fedora
1

Hi!

I have the following setup:
100 Fedora 41 VMs each 4 GB RAM running on 128 GB server (laptop).
All VMs have the same setup.
Especially all have “autopart --type=lvm” (kickstart setup)
This is working because KSM (kernel samepage merging) is working very very well.
I use:
echo 1 > /sys/kernel/mm/ksm/run
echo 100000 > /sys/kernel/mm/ksm/pages_to_scan
Inside the VM I fill up the memory with “rpm -Vaq” (mostly filesystem cache).
Outside after some time there is no swap usage and there are even about 40 GB free.
“top” really shows 100 processes (“qemu-system-x86”) each having 4,0g RSS.

I now tried to use “autopart --type=btrfs” for the VM setup,
but with that the saving through KSM is much less.

The only change in the kickstart file is:
“autopart --type=lvm” → “autopart --type=btrfs”

Is this a known behavior and can I do something to improve this keeping with btrfs?

Thank you
Christoph

2

My guess is that what you are seeing is the checksum feature of btrfs data integrity making the meta data cached by the kernel different in each VM.

3

Is there a way to read these checksums so that I can compare them?
Just to be sure it is this feature.

4

That would require knowledge of the btrfs disk format and in kernel structures. I do not have that knowledge.

5

You might ask your question on the upstream Btrfs list. it may just be that the work for KSM hasn’t happened in Btrfs yet. And you’d need to ask the developers if it’s planned.

X-Mailing-List: linux-btrfs@vger.kernel.org
List-Id: <linux-btrfs.vger.kernel.org>
List-Subscribe: <mailto:linux-btrfs+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-btrfs+unsubscribe@vger.kernel.org>

Btrfs makes prolific use of UUIDs. Every Linux flie system uses a file system UUID to distinguish it from another. But Btrfs writes that UUID into every single metadata leaf and node. Is there’s some efficiency optimization with KSM that permits “deduplication” of on-disk pages that are identical across 40 VMs because their file system metadata blocks are largely identical? And if so, what’s the consequence of 40 file systems having unique metadata blocks even though their file system data is identical?

I have no idea, and also am unfamiliar with KSM functionality. So this above is pure speculation. And also, the file system metadata should be quite small, and I don’t know if or how the on-disk format differs from the in-memory format.