Thanks Erick and Bowen I do find all the different parameters for repairs confusing, and even reading up on it now, I see Datastax warns against incremental repairs with -pr, but then the code here seems to negate the need for this warning.
Anyway running it like this, produces data in the system.repairs table, so I assume it is doing incremental repairs. nodetool -h localhost -p 7199 repair -pr -st +02596488670266845384 -et +02613877898679419724 Then running it like this produces no data in the table, so again assuming that means it is full repairs nodetool -h localhost -p 7199 repair -pr -full -st +02596488670266845384 -et +02613877898679419724 Yesterday I recompiled the Cassandra 4.0.0 code with extra logging in the following method https://github.com/apache/cassandra/blob/6709111ed007a54b3e42884853f89cabd38e4316/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L338 <https://github.com/apache/cassandra/blob/6709111ed007a54b3e42884853f89cabd38e4316/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L338> This showed me that the extra 10 minutes ( and more ) on some clusters is being taken up in the for loop reading the rows from the system.repairs table. So this does seem to be issue if you are trying to do incremental range repairs in 4.0 Thanks Paul > On 27 Jan 2022, at 10:27, Bowen Song <bo...@bso.ng> wrote: > > Hi Erick, > > > > From the source code: > https://github.com/apache/cassandra/blob/6709111ed007a54b3e42884853f89cabd38e4316/src/java/org/apache/cassandra/service/StorageService.java#L4042 > > <https://github.com/apache/cassandra/blob/6709111ed007a54b3e42884853f89cabd38e4316/src/java/org/apache/cassandra/service/StorageService.java#L4042> > The -pr option has no effect if -st and -et are specified. Therefore, the > command results in an incremental repair. > > > > Cheers, > > Bowen > > On 27/01/2022 01:32, Erick Ramirez wrote: >> I just came across this thread and noted that you're running repairs with >> -pr which are not incremental repairs. Was that a typo? Cheers!