On Do, 2021-07-01 at 13:34 +0200, Christoph Hellwig wrote: > On Thu, Jul 01, 2021 at 12:35:53PM +0200, Martin Wilck wrote: > > I respectfully disagree. Users of dm-multipath devices expect that > > IO > > succeeds as long as there's at least one healthy path. This is a > > fundamental property of multipath devices. Whether IO is sent > > "normally" or via SG_IO doesn't make a difference wrt this > > expectation. > > If you have those (pretty reasonable) expections don't use SG_IO. > That is what the regular read/write path is for. SG_IO gives you > raw access to the SCSI logic unit, and you get to keep the pieces > if anything goes wrong. With this logic, if some paths are down, SG_IO commands on multipath devices yield random results. On one path a command would fail, and on another it would succeed. User space has no way to control or even see what path is being used. That's a very fragile user space API, on the fringe of being useless IMO. If user space is interested in the error handling semantics you describe, it can run SG_IO on individual SCSI devices any time. With the change I am proposing, nothing is lost for user space. If user space decides to do SG_IO on a multipath device, it has a different expectation, which my patch set implements. IMO we should strive to match the semantics for ioctls on natively multipathed NVMe namespaces. Regards Martin
