blob: d42a50bacb086e00f30d442af6770847f953757c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, I'm trying to classify this bug report as either 'user-mode' or 'system-mode'. The user is experiencing an issue where using qemu-nbd in read-only mode (-r) on a device leaves it tainted for subsequent use. Even after detaching with -d, the next connection in read-write mode fails.
Looking at what's happening: when they connect to /dev/nbd2 in read-only mode and then detach, later attempts to attach another image in read-write mode result in an error during mkfs. The system says "Operation not permitted while setting up superblock", which suggests that the device isn't allowing write operations.
Qemu-nbd is a userland tool used for connecting disk images to Network Block Devices (NBD). It operates with higher privileges because it's interacting directly with kernel devices. The issue here seems related to how the NBD device (/dev/nbd2) is being left in a state that affects subsequent uses, even after detaching.
The fact that this involves device state persistence across different connections and requires cleaning up with -d suggests that it's an issue with how the device driver handles its state. The kernel-level driver for NBD might not be properly resetting or releasing resources when a read-only connection is made, leading to the next connection in write mode being blocked.
Since this involves interaction between user-space tools (qemu-nbd) and kernel drivers, but the problem persists across detach and reattach, it's likely related to how the kernel handles the device state. Therefore, this bug seems more system-mode related because it touches on device handling and driver behavior.
</think>
system
|