Increasing the queue size to handle container storage workloads

[HuijingHei]

Just test to see if this could workaround #174

[gemini-code-assist]

Code Review

This pull request increases the virtiofs queue size from 1024 to 4096, presumably to improve performance for storage-intensive workloads. While the change is simple, I've identified a couple of issues. First, the new queue size is a hardcoded 'magic number'; I've suggested extracting it into a constant for better maintainability. Second, and more critically, the unit tests for this functionality in test_virtiofs_filesystem_configuration within crates/kit/src/libvirt/domain.rs have not been updated to reflect this change, causing them to fail. Please update the tests to assert the new queue size of 4096.

[gemini-code-assist]

The virtiofs queue size 4096 is a magic number. To improve readability and maintainability, it's best to define this as a constant. This also makes it easier to update in the future and to reference from tests.

The tests in test_virtiofs_filesystem_configuration are currently failing because they still assert the old queue size of 1024. Using a constant would help resolve this and prevent it from happening in the future.

You can add the following constant at the top of the file:

const VIRTIOFS_QUEUE_SIZE: &str = "4096";

Then, use this constant here and in the tests.

Suggested change

	writer.write_empty_element("driver", &[("type", "virtiofs"), ("queue", "4096")])?;
	writer.write_empty_element("driver", &[("type", "virtiofs"), ("queue", VIRTIOFS_QUEUE_SIZE)])?

[cgwalters]

I don't have any theory offhand why increasing the queue size here would make a difference - unless it somehow could relate to the maximum number of fds?

Either way it's probably useful to have an explicit rationale for why we picked the number. A reference to another virt framework (libvirt or systemd-vmspawn) could make sense here.

[HuijingHei]

I don't have any theory offhand why increasing the queue size here would make a difference - unless it somehow could relate to the maximum number of fds?

The change was proposed by AI, and I meant want to give it a try, though I do not sure about this.

[HuijingHei]

Thank you! Looks this is not great to set to 4096, will close this and find another workaround.

Potential upside
Slight improvement only if:

- Very high parallel fs ops
- Many vCPUs (≥16–32)
- Heavy metadata churn (massive parallel builds, stress tests)

[cgwalters]

The change was proposed by AI,

That's fine, though why was this commit missing the attribution?
https://github.com/bootc-dev/infra/blob/2dd498656b9653c321e5d9a8600e6b506714acb3/common/AGENTS.md#attribution

Not a big deal, but it's really helpful to know in general when one is looking at something a human thought vs something that came from AI or a hybrid.