search for: rescanning

...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 all user all mailbox index every night, would that be appropriate? Would running this every night avoid the need to ever rescan? Should I run rescan instead of index? Should I run both rescan and index? In which order? Best Regards, FredK

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, 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

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

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

Hello Julius, Thanks - but it doesn't seem to work. I installed sg3_utils and ran #scsi-rescan but that seemed to have done nothing for some reason. Cheers, Boris. On Wed, Nov 4, 2015 at 10:12 AM, Tnjulius <tnjulius at gmail.com> wrote: > Hi Boris, > Just rescan the scsi host. > #scsi-rescan #if you have sg3_utils package > #lsscsi > Or > #echo "- - -"

> 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, 28 Aug 2020 12:21:35 +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 0.

Hi, I'm using Dovecot 2.2.13 with Dovecot Director, Doveadm server and FTS. I want to run doveadm on Director hosts, but Dovecot server on backend hosts reject "fts *" commands. On Dovecot Director hosts: # doveadm fts optimize -u u0001 at example.jp # echo $? 75 # doveadm fts rescan -u u0001 at example.jp # echo $? 75 doveadm index -u u0001 at example.jp INBOX #

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

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 11/04/2015 10:27 AM, Mauricio Tavares wrote: > On Wed, Nov 4, 2015 at 10:22 AM, Boris Epstein <borepstein at gmail.com> wrote: >> Hello Julius, >> >> Thanks - but it doesn't seem to work. >> >> I installed sg3_utils and ran >> #scsi-rescan >> >> but that seemed to have done nothing for some reason. >> > Dumb question:

The kernel side for rescan, which is needed if you want to enable qgroup tracking on a non-empty volume. The first patch splits btrfs_qgroup_account_ref into readable ans reusable units. The second patch adds the rescan implementation (refer to its commit message for a description of the algorithm). The third patch starts an automatic rescan when qgroups are enabled. It is only separated to

...ling CentOS 5.1 (did not notice this problem with CentOS 5) i cannot seem to rescan without huge problems. Sometimes when i rescan after presenting a new LUN to the server nothing is detected, and sometimes the device comes in without any problems at all. Sometimes i even loose some paths after rescanning.....again, i had no problems at all with CentOS 4.x. I use the Qlogic script (Dynamic Target and LUN Discovery <http://support.qlogic.com/support/EULATemplate/Template.aspx?TemplateID=9&path=http://download.qlogic.com/ms/56614/ql-dynamic-tgt-lun-disc-2.2.tgz> 2.2) to scan for new luns...

Hi all, I hope this is possible. I have a server, with a network switch attached to the serial port, and I want to rescan the serial port (/dev/tty) to see if it picks it up? I'd prefer not to reboot the server if at all possible. dmesg reports ttyS0 as the active port: [root at zabackup01 ~]# dmesg |grep tty Bootdata ok (command line is ro root=/dev/System/root rhgb quiet xencons=tty6)

On Fri, Apr 05, 2019 at 19:33:57 +0800, Joan Moreau via dovecot wrote: > Hi > > If you plan to fix the FTS part of Dovecot, I will be very gratefull. I'm trying to figure out what is causing the 3rd issue you listed, so we can decide how severe it is and therefore how quickly it needs to be fixed. At the moment we are unable to reproduce it, and therefore we cannot fix it. >

Hi list, I have a SAN attached to a CentOS 4.2 server. I have expanded the size of the virtual disk within the SAN (by adding a new HD to the disk pool) and need CentOS to see the new size (CentOS see it as /dev/sdb). I'm using LVM. Do you know a method for the Volume Group to see that one of its harddisk is now bigger, without rebooting (it's not a problem with a reboot but since

I have tried to spend some time of understanding the logic (if any !) of the fts part Honestly, the one who created this mess shall be the one to fix it, or one shall refactor it totally. Basically, the fts "core" should be able to do - select the backend according to conf file - send new emails/maiblox to backend - send teh ID of the emails to be removed - resend an entire

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! --