1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
<think>
Okay, so I need to classify this bug report into one of the given categories. Let me read through the problem again carefully.
The issue is about file locks specifically F_OFD_SETLK and F_OFD_GETLK not being supported correctly in QEMU. The function `qemu_probe_lock_ops()` is checking if these lock types are supported by testing on `/dev/null`. However, this might give a wrong result because `/dev/null` is a special file and may not behave like regular files or other filesystems.
The problem arises when disk images are stored on a shared filesystem, especially with something like Quobyte which uses FUSE. The test in QEMU assumes that if the OS supports these locks on any file (like /dev/null), then all filesystems will support them. But this isn't necessarily true, as some filesystems might not handle OFD locks correctly.
The user mentioned that this leads to VM crashes when OpenStack tries to create a snapshot. They also provided kernel and QEMU versions, but couldn't find the exact source of the packages used by the Ubuntu Cloud Archive.
Looking at the categories:
- **mistranslation**: Incorrect mapping from source to target, more about architecture or IR issues. Doesn't fit here.
- **assembly**: Lowering assembly code. Not relevant here as it's a filesystem issue.
- **device**: Could be related to device drivers or special files like /dev/null, but the problem is with file locking in general.
- **graphic**, **socket**, **network**, **KVM**, **boot**, **vnc**, **debug**, **files**, **permissions**, **performance**, **kernel**, **peripherals**, **hypervisor**: These don't directly relate to file locking.
The issue is specifically about filesystem operations and whether the locks are supported correctly. It's a problem with how QEMU checks for lock support, which affects disk image handling. Therefore, it falls under the **files** category because it's related to file operations and permissions.
</think>
files
|