An issue recently came up where remote NVMe devices reported "unusual" values for its Optimal Write Size; this is used by Linux to, among other things, determine read-ahead size. The invalid value led to a read-ahead size of 64MiB which creates significant performance issues on random-read workloads.
It might be nice to inspect both the NVMe namespace and the sysfs file to ensure the value is somewhere in the ballpark of reasonable or come up with a table of exact values so it's obvious if any of the defaults change. I'm not sure this is exactly in the realm of LISA's focus, as it's more of a test of Azure than the distribution's quality, although Linux could conceivably change how it calculates read-ahead in a way that has a performance impact on Azure workloads and it'd be good to be aware of that.
An issue recently came up where remote NVMe devices reported "unusual" values for its Optimal Write Size; this is used by Linux to, among other things, determine read-ahead size. The invalid value led to a read-ahead size of 64MiB which creates significant performance issues on random-read workloads.
It might be nice to inspect both the NVMe namespace and the sysfs file to ensure the value is somewhere in the ballpark of reasonable or come up with a table of exact values so it's obvious if any of the defaults change. I'm not sure this is exactly in the realm of LISA's focus, as it's more of a test of Azure than the distribution's quality, although Linux could conceivably change how it calculates read-ahead in a way that has a performance impact on Azure workloads and it'd be good to be aware of that.