Qubes does not distinguish rotational drives resulting in wrong I/O scheduler values

[qubist]

Hi,

I have noticed that Qubes doesn't seem to distinguish rotational and
non-rotational drives in relation to the I/O scheduler.

This is a rotational HDD connected using a USB docking station,
attached to a domU through qui-devices:

$ cat /sys/block/xvdi/queue/scheduler
[none] mq-deadline kyber bfq # should be [cfq] or [bfq]
$ cat /sys/block/xvdi/queue/rotational
0 # should be 1

What is the reason for this (if it is intentional) or does it deserve to be
reported on GitHub (if it is not)?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Sep 30, 2026 at 05:50:39PM -0000, qubist wrote:
> Hi,
>
> I have noticed that Qubes doesn't seem to distinguish rotational and
> non-rotational drives in relation to the I/O scheduler.
>
> This is a rotational HDD connected using a USB docking station,
> attached to a domU through qui-devices:
>
> $ cat /sys/block/xvdi/queue/scheduler
> [none] mq-deadline kyber bfq # should be [cfq] or [bfq]
> $ cat /sys/block/xvdi/queue/rotational
> 0 # should be 1

A qube (kinda intentionally) knows very little about the hardware it's
connected to. In this case it's an external disk directly, but it could
be also for example a file with disk image or an encrypted volume - and
it would look the same from the qube point of view.
Note the backend does see what hardware is there, and may apply its own
scheduling decisions.

But, maybe for the case of a block device connected directly
(qvm-block), some extra information could be provided? I'm not sure if
the current protocol has space for that (it's intentionally quite
simplistic), requires some research.

> What is the reason for this (if it is intentional) or does it deserve to be
> reported on GitHub (if it is not)?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmq9WH0ACgkQ24/THMrX
1yyBaAf/TwKx901likboI0occgHLIPpasUGt1AZ808WbvVxFES+xvJ14qu+/Qs04
sCjCm2BtY2FoJ0efIDMzVjO5zJMus3mdYVVTxA7nkZMYPN49pexq+h5Uh1G5BGsi
1gee1z/IOR5RU+1rQMYVaT4pebnIkXdHzDofdm4sD43UBbxm0WecyF6L9LlbKrOg
k/eywO2xwLqvkXYhCRCrGMzZl3D4QUKzlgwNyOpQSg6MDhL7C26DmI4tFgqPH0gC
JGbQs9Ekw25nmYFYpCESZpWS7QUTWX+VwLeKx7F//Ngv0wHP686SzqmCiDETnMgu
t4ZvOQuN7tYRYdxTbYtKPYW5b/Y78A==
=YzGU
-----END PGP SIGNATURE-----

[qubist]

On Wed, 30 Sep 2026 20:44:13 +0200 Marek Marczykowski-Górecki wrote:

> A qube (kinda intentionally) knows very little about the hardware it's
> connected to.

smartctl can see the full info about the drive in that same qube, i.e.
the qube knows enough in the particular case of attaching an external
LUKS-encrypted drive.

> In this case it's an external disk directly, but it could
> be also for example a file with disk image or an encrypted volume -
> and it would look the same from the qube point of view.

Then sys-usb would know about the hardware. Perhaps sys-usb can tell
the client qube "I am sending you a rotational" which can be just a
single 0/1 flag.

> Note the backend does see what hardware is there, and may apply its
> own scheduling decisions.

What do you mean by backend that applies its own scheduling decisions?
AFAIK it is the kernel that does that.