Re: [PATCH] sd: do not set changed flag on all unit attentionconditions
From: James Bottomley
Date: Tue Jul 17 2012 - 05:11:59 EST
On Tue, 2012-07-17 at 10:54 +0200, Paolo Bonzini wrote:
> Il 17/07/2012 10:40, James Bottomley ha scritto:
> >> >
> >> > It's not specific to virtio-scsi, in fact I expect that virtio-scsi will
> >> > be almost always used with non-removable disks.
> >> >
> >> > However, QEMU's SCSI target is not used just for virtio-scsi (for
> >> > example it can be used for USB storage), and it lets you mark a disk as
> >> > removable---why? because there exists real hardware that presents itself
> >> > as an SBC removable disk. The only thing that is specific to
> >> > virtualization, is support for online resizing (which generates a unit
> >> > attention condition CAPACITY DATA HAS CHANGED).
> > So what's the problem? If you're doing pass through of a physical disk,
> > we pick up removable from its inquiry string ... a physical removable
> > device doesn't get resized. If you have a virtual disk you want to
> > resize, you don't set the removable flag in the inquiry data.
> In practice people will do what you said, and it's not a problem.
> However, there's nothing that prevents you from running qemu with a
> removable SCSI disk, and then resizing it. I would like this to work,
> because SBC allows it and there's no reason why it shouldn't.
There's no such thing in the market today as a removable disk that's
resizeable. Removable disks are for things like backup cartridges and
ageing jazz drives. Worse: most removeable devices today are USB card
readers whose standards compliance varies from iffy to non existent.
Resizeable disks are currently the province of storage arrays.
We don't do stuff just because the standards allows it; just the
opposite: we try to use the smallest implementations from the standards
we can get away with just because the more things we do, the more
exceptions and broken devices we come across.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/