qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 08/12] block: Catch attempt to attach multip


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: [PATCH 08/12] block: Catch attempt to attach multiple devices to a blockdev
Date: Mon, 28 Jun 2010 10:24:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4

Am 27.06.2010 11:36, schrieb Christoph Hellwig:
> On Sat, Jun 26, 2010 at 04:44:11PM +0200, Markus Armbruster wrote:
>> Valid question.  I'd answer yes.  It's an easy error to make, and likely
>> to end in massive file system corruption in the guest.
> 
> I suspect a modern distro in the guest will detect it as a multi-path setup.
> 
>>> Can anyone explain what the hell usb storage is actually trying to do
>>> with the two drives?
>>
>> It's actually a SCSI controller with a single drive on its single bus.
>>
>> -device usb-storage,drive=foo creates *two* devices: usb-storage itself,
>> which serves as SCSI controller, and scsi-disk for the drive.
>> usb-storage copies its drive property to scsi-disk.
>>
>> I don't like this.  Each -device should create just one device.
> 
> Indeed.  I'd also prefer to get rid of this.  Anthony, how hard are the
> rules on backwards compatiblity for things like this?

How would breaking compatibility help us? For the user a USB MSD is only
one device, so requiring two -device parameters sounds wrong.

If anything, scsi-disk must change to be able to share code without
requiring a device - and this is a change that would be kept internal
with no change on the user interface.

Or are you just talking about things like migration between versions
which would very likely break? That would probably be okay for USB MSD.

> Note that currently the usb storage emulation is extremly broken anyway,
> just writing to it produces I/O errors after a short while.  This means
> it can't be used very much at all.

When I tried last time, it did produce lots of kernel error messages in
the guest, but in the end the data was written correctly. So it doesn't
seem to be completely unusable.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]