On Tue, May 13, 2025 at 09:57:51PM -0700, Christoph Hellwig wrote: > On Tue, May 13, 2025 at 11:29:09AM +0200, Kevin Wolf wrote: > > Am 13.05.2025 um 07:55 hat Christoph Hellwig geschrieben: > > > On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote: > > > > Yes, it's a bit unfortunate, but we have to work with what we have. QEMU > > > > doesn't even necessarily know that it's dealing with a multipath device, > > > > so it just has to blindly try the ioctl and see if it works. > > > > > > Why is qemu even using SG_IO to start with? > > > > How else would you do SCSI passthrough? > > > > Ok, from your replies to Hannes I understand an implicit message, you > > wouldn't. But I don't think that's really an answer, at least not for > > all users. > > SG_IO is fine and the only way for SCSI passthrough. But doing > SCSI passthrough through md-multipath just doesn't work. SCSI isn't > built for layering, and ALUA and it's vendor-specific variants and > alternatives certainly isn't. If you try that you're playing with > fire and is not chance of ever moving properly.
Could you be a bit more specific. All multipath is doing here is forwarding the ioctls to an underlying scsi device, and passing back up the result. Admittedly, it doesn't always make sense to pass the ioctl on from the multipath device to just one scsi device. Persistent Reservations are perfect example of this, and that's why QEMU doesn't use DMs ioctl passthrough code to handle them. Also, when you have ALUA setups, not all the scsi devices are equal. But multipath isn't naievely assuming that they are. It's only passing ioctls to the highest priority activated paths, just like it does for IO, and multipath is in charge of handling explicit alua devices. This hasn't proved to be problematic in practice. The reality of the situation is that customers have been using this for a while, and the only issue that they run into is that multipath can't tell when a SG_IO has failed due to a retryable error. Currently, they're left with waiting for multipathd's preemptive path checking to fail the path so they can retry down a new one. The purpose of this patchset and Martin's previous one is to handle this problem. If there are unavoidable critical problems that you see with this setup, it would be really helpful to know what they are. -Ben
