blob: 6549ccb9eace1e797e1f163ae1e2ef94f3de61ae (
plain) (
blame)
1
2
3
4
5
6
7
8
9
|
<think>
Okay, I need to classify the given bug report into one of the provided categories for QEMU. Let me read through the details carefully. The issue mentions that the physical_block_size is restricted to uint16_t, which limits it to a maximum of 65536. However, they want to set it to 4194304 for RBD-backed storage, but this isn't possible due to the restriction. It's noted that scsi-hd.discard_granularity doesn't have this issue and works fine.
So, the problem is about a limitation in data types affecting configuration options related to storage devices. The bug report is pointing out an incorrect semantic mapping because physical_block_size uses uint16_t, which can't handle larger values. This falls under translation issues from user-mode or source architecture to IR/target. Therefore, it's classified as 'mistranslation'.
</think>
The bug report discusses a limitation in the storage configuration where physical_block_size is restricted by using a uint16_t data type, limiting its maximum value. Since this affects how the feature translates and handles values, it falls under 'mistranslation'.
**Answer:** mistranslation
|