On Thu, May 15, 2025 at 12:11:49PM +0200, Kevin Wolf wrote:
> If you're talking about SG_IO in dm-mpath, then PRIN/PROUT commands are
> actually the one thing that we don't need. libmpathpersist sends the
> commands to the individual path devices, so dm-mpath will never see
> those. It's mostly abo
On Thu, May 15, 2025 at 05:00:41PM +0200, Martin Wilck wrote:
> I didn't mean it this way. I was rather musing about the question
> whether doing SG_IO on multipath devices by forwarding them to the
> current path makes sense.
It doesn't, and that's the core of the problem. Someone back in the
da
On Tue, May 13, 2025 at 12:29:51PM -0400, Benjamin Marzinski wrote:
> On Mon, May 12, 2025 at 11:49:19PM -0700, Christoph Hellwig wrote:
> > On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> > > Reservations and stuff.
> >
> > They should use the kernel persistent reservation API.
Grabbing the work_mutex keeps probe_active_paths() from running at the
same time as multipath_message(). The only messages that could interfere
with probing the paths are "disable_group", "enable_group", and
"switch_group". These messages could force multipath to pick a new
pathgroup while probe_ac
On Thu, 2025-05-15 at 13:09 +0200, Paolo Bonzini wrote:
> However, EBADE handling dates back to 2011 (commit 63583cca745f,
> "[SCSI]
> Add detailed SCSI I/O errors", 2011-02-12) and yet the Windows tests
> for
> PR were failing before QEMU switched to SG_IO for reads and writes.
> I
> guess I
On Thu, 2025-05-15 at 12:11 +0200, Kevin Wolf wrote:
> Am 14.05.2025 um 23:21 hat Martin Wilck geschrieben:
>
> > In the long term, we should evaluate alternatives. If my conjecture
> > in
> > my previous post is correct we need only PRIN/PROUT commands, there
> > might be a better solution than
On Thu, 2025-05-15 at 10:29 -0400, Benjamin Marzinski wrote:
> On Thu, May 15, 2025 at 12:34:13PM +0200, Martin Wilck wrote:
> >
> > However, I suppose that depends on the permissions with which the
> > qemu
> > process is started, no? Wouldn't qemu need CAP_SYS_RAWIO for PCI
> > passthrough as we
On Thu, 2025-05-15 at 12:51 +0200, Paolo Bonzini wrote:
> On Thu, May 15, 2025 at 12:34 PM Martin Wilck
> >
> > Thanks for mentioning this. However, I suppose that depends on the
> > permissions with which the qemu process is started, no? Wouldn't
> > qemu need CAP_SYS_RAWIO for PCI passthrough
On Thu, May 15, 2025 at 12:34:13PM +0200, Martin Wilck wrote:
> On Thu, 2025-05-15 at 04:53 +0200, Paolo Bonzini wrote:
> > Il mer 14 mag 2025, 13:37 Martin Wilck ha scritto:
> > >
> > > I'd go one step further. Christoph is right to say that what we're
> > > currently doing in qemu – passing thr
Hi
于 2025年5月14日 GMT+08:00 13:17:47，Christoph Hellwig 写道：
>On Tue, May 13, 2025 at 05:32:13PM +0800, Yu Kuai wrote:
>> I was thinking about record a stack dev depth in mddev to handle the
>> weird case inside raid. Is there other stack device have the same
>> problem? AFAIK, some dm targets like d
On 5/14/25 22:50, Bart Van Assche wrote:
> Improve code readability by using bdev_is_zone_aligned() and
> bdev_offset_from_zone_start() where applicable. No functionality
> has been changed.
>
> This patch is a reworked version of a patch from Pankaj Raghav.
>
> See also
> https://lore.kernel.or
On 5/14/25 06:53, Christoph Hellwig wrote:
And no, passing the SCSI devices to the VM and doing multipath in the
the guest doesn't work. The transport layer isn't properly emulated
(bluntly speaking, we have no FC emulation).
Then fix that. Because without it you will be in never ending pain
d
On Thu, May 15, 2025 at 12:34 PM Martin Wilck wrote:
> On Thu, 2025-05-15 at 04:53 +0200, Paolo Bonzini wrote:
> > Il mer 14 mag 2025, 13:37 Martin Wilck ha scritto:
> > Yes, as usual things are a bit more complicated. First, a handful of
> > commands are special (REQUEST SENSE would be for HBAs
On 5/15/25 12:11, Kevin Wolf wrote:
The thing that we need to make sure, though, is that the emulated status
we can expose to the guest is actually good enough. That Paolo said that
the problem with reservation conflicts was mostly because -EBADE wasn't
a thing yet gives me some hope that at leas
On Thu, 2025-05-15 at 04:53 +0200, Paolo Bonzini wrote:
> Il mer 14 mag 2025, 13:37 Martin Wilck ha scritto:
> >
> > I'd go one step further. Christoph is right to say that what we're
> > currently doing in qemu – passing through every command except the
> > PRIN/PROUT to a multipath device – is
Am 14.05.2025 um 23:21 hat Martin Wilck geschrieben:
> On Tue, 2025-05-13 at 10:00 +0200, Martin Wilck wrote:
> > > If you think it does, is there another reason why you didn't try
> > > this
> > > before?
> >
> > It didn't occur to me back then that we could fail paths without
> > retrying in the
16 matches
Mail list logo
