similar to: [PATCH] Rescan the entire target on transport reset when LUN is 0

> On Sep 8, 2020, at 3:22 PM, Paolo Bonzini <pbonzini at redhat.com> wrote: > > On 28/08/20 14:21, Matej Genci wrote: >> VirtIO 1.0 spec says >> The removed and rescan events ... when sent for LUN 0, they MAY >> apply to the entire target so the driver can ask the initiator >> to rescan the target to detect this. >> >> This change

On Fri, Aug 28, 2020 at 12:21:35PM +0000, Matej Genci wrote: > VirtIO 1.0 spec says > The removed and rescan events ... when sent for LUN 0, they MAY > apply to the entire target so the driver can ask the initiator > to rescan the target to detect this. > > This change introduces the behaviour described above by scanning the > entire scsi target when LUN is set to

On 28/08/20 14:21, Matej Genci wrote: > VirtIO 1.0 spec says > The removed and rescan events ... when sent for LUN 0, they MAY > apply to the entire target so the driver can ask the initiator > to rescan the target to detect this. > > This change introduces the behaviour described above by scanning the > entire scsi target when LUN is set to 0. This is both a

On 28/08/20 14:21, Matej Genci wrote: > VirtIO 1.0 spec says > The removed and rescan events ... when sent for LUN 0, they MAY > apply to the entire target so the driver can ask the initiator > to rescan the target to detect this. > > This change introduces the behaviour described above by scanning the > entire scsi target when LUN is set to 0. This is both a

Matej, > This change introduces the behaviour described above by scanning the > entire scsi target when LUN is set to 0. This is both a functional and a > performance fix. It aligns the driver with the spec and allows control > planes to hotplug targets with large numbers of LUNs without having to > request a RESCAN for each one of them. Applied to 5.10/scsi-staging, thanks! --

On Mon, Sep 02, 2019 at 09:56:42AM +0000, Matej Genci wrote: > On 8/31/2019 6:43 PM, Michael S. Tsirkin wrote: > > On Fri, Aug 30, 2019 at 05:58:23PM +0000, Matej Genci wrote: > >> On 8/30/2019 3:02 PM, Michael S. Tsirkin wrote: > >>> On Tue, Aug 27, 2019 at 03:20:57PM +0000, Matej Genci wrote: > >>>> Compilers such as g++ 7.3 complain about assigning

From: Matej Genci <matej.genci at nutanix.com> Add macro to disable legacy vring functions. Signed-off-by: Matej Genci <matej.genci at nutanix.com> Link: https://lore.kernel.org/r/20190911124942.243713-1-matej.genci at nutanix.com Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_modern.c | 1 + include/uapi/linux/virtio_ring.h | 4 ++++ 2

From: Matej Genci <matej.genci at nutanix.com> Add macro to disable legacy vring functions. Signed-off-by: Matej Genci <matej.genci at nutanix.com> Link: https://lore.kernel.org/r/20190911124942.243713-1-matej.genci at nutanix.com Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_modern.c | 1 + include/uapi/linux/virtio_ring.h | 4 ++++ 2

From: Matej Genci <matej.genci at nutanix.com> Add macro to disable legacy vring functions. Signed-off-by: Matej Genci <matej.genci at nutanix.com> Link: https://lore.kernel.org/r/20190911124942.243713-1-matej.genci at nutanix.com Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_modern.c | 1 + include/uapi/linux/virtio_ring.h | 4 ++++ 2

From: Matej Genci <matej.genci at nutanix.com> Add macro to disable legacy vring functions. Signed-off-by: Matej Genci <matej.genci at nutanix.com> Link: https://lore.kernel.org/r/20190911124942.243713-1-matej.genci at nutanix.com Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_modern.c | 1 + include/uapi/linux/virtio_ring.h | 4 ++++ 2

From: Matej Genci <matej.genci at nutanix.com> Add macro to disable legacy vring functions. Signed-off-by: Matej Genci <matej.genci at nutanix.com> Link: https://lore.kernel.org/r/20190911124942.243713-1-matej.genci at nutanix.com Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_modern.c | 1 + include/uapi/linux/virtio_ring.h | 4 ++++ 2

From: Matej Genci <matej.genci at nutanix.com> Add macro to disable legacy vring functions. Signed-off-by: Matej Genci <matej.genci at nutanix.com> Link: https://lore.kernel.org/r/20190911124942.243713-1-matej.genci at nutanix.com Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci_modern.c | 1 + include/uapi/linux/virtio_ring.h | 4 ++++ 2

On Fri, Sep 06, 2019 at 12:42:14PM +0000, Matej Genci wrote: > Add macro to disable legacy functions vring_init and vring_size. > > Signed-off-by: Matej Genci <matej.genci at nutanix.com> > --- > include/uapi/linux/virtio_ring.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h >

On Tue, Sep 10, 2019 at 05:53:44PM +0000, Matej Genci wrote: > Add macro to disable legacy functions vring_init and vring_size. > > Signed-off-by: Matej Genci <matej.genci at nutanix.com> > --- > > V2: Put all legacy APIs inside guards. > > --- > include/uapi/linux/virtio_ring.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git

On Tue, Sep 10, 2019 at 05:53:44PM +0000, Matej Genci wrote: > Add macro to disable legacy functions vring_init and vring_size. > > Signed-off-by: Matej Genci <matej.genci at nutanix.com> And I guess we should be able to define this macro in drivers/virtio/virtio_pci_modern.c ? Will be handy to make sure we don't mask too much. > --- > > V2: Put all legacy APIs

Not really, as the steps outlined by Timo would not get done. Aki > On 17 February 2019 at 10:56 Joan Moreau via dovecot <dovecot at dovecot.org> wrote: > > > In such case, as long as the API is not upgraded, should > > doveadm index -A -q \* > > be considered a replacement of > > doveadm fts rescan > > On 2019-02-14 16:24, Timo Sirainen via

I've had squat running on dovecot 2.0 and have been updating all users mailbox indexes nighty via cron with this command: doveadm -v search -A text xyzzyx I've just updated to 2.1 and I'm migrating to lucene indexes, but reading the documentation I'm having a hard time understanding the semantic differences between indexing and rescanning. If I were to continue to run an

In such case, as long as the API is not upgraded, should doveadm index -A -q \* be considered a replacement of doveadm fts rescan On 2019-02-14 16:24, Timo Sirainen via dovecot wrote: > Hi, > > The rescan() function is a bit badly designed. Currently what you could do what fts-lucene does and: > - Get list of UIDs for all mails in each folder > - If Xapian has UID that

Hi Christian, may be the issue is related to this other post: http://dovecot.org/pipermail/dovecot/2015-September/102094.html Anyway, what I can tell you is that for every? user account,? for every folders created after the last doveadm fts rescan for that user, dovecot does not invoke indexer. A new rescan fix the problem for all the folders created up to that moment. I was wondering if I was

Hi, THis is a core problem in Dovecot in my understanding. In my opinion, the rescan in dovecot should send to the FTS plugin the list of "supposedly" indexed emails (UID), and the plugin shall purge the redundant UID (i..e UID present in the index but not in the list sent by dovecot) and send back the list of UID not in its indexes to dovecot, so Dovect can send one by one the