TS001515941 - Probleme mit AutoRepair Funktion

[eknori]

Ich habe diese Funktion in Beta 1 & 2 rauf und runter getestet; leider war zu diesem Zeitpunkt der DAOS Part noch nicht verfügbar.  Nach Veröffentlichung von V10 habe ich dann diesen Part getestet.
Hier liegt m.E. einiges im Argen. Der u.a. Test ist nur einer von einer ganzen Reihe von Tests. Leider komme ich in den einzelnen Tests zu sehr unterschiedlichen Ergebnissen bei Punkt 1. Es gibt auch Unterschiede, ob ich unter WIN oder LIN teste.

Punkt 2 schlägt immer fehl.

I tried to test the new file repair function in V10 GA and found it not working as expected.
My environment is a cluster with 2 servers ( serv01 = Windows, serv02 = LINUX )
Mailfiles are DAOS enabled.
 
1. Delete a database on the file system
I deleted database mail/srossner.nsf from the filesystem and waited for the autorepair to kick in.
 
[017735:000002-00007FD0B8F0D740] REPAIR: 1 file(s) queued for repair
[002723:000044-00007F961B060700] REPAIR: Job-00004.1 *Copying* - mail/srossner.nsf from CN=serv01/O=singultus
[002723:000044-00007F961B060700] REPAIR: Job-00004.2 *Error* - Releasing buffers for CN=serv01/O=singultus: Remote system no longer responding
 
But serv01 is up and running; I verified immediately with
 
pull CN=serv01/O=singultus
 
> [012083:000002-00007F2225D39740] 22.10.2018 13:46:40   Database Replicator started
[012083:000002-00007F2225D39740] 22.10.2018 13:46:40   Replicator is set to Ignore Database Quotas
[012083:000002-00007F2225D39740] 22.10.2018 13:46:40   Starting replication with server serv01/singultus
[012083:000002-00007F2225D39740] 22.10.2018 13:46:41   Pulling ddm.nsf from serv01/singultus ddm.nsf
 
Then, after a while
 
[002723:000044-00007F961B060700] REPAIR: Job-00005.1 *Copying* - mail/srossner.nsf from CN=serv01/O=singultus
[002723:000044-00007F961B060700] REPAIR: Job-00005.2 *Copy Completed* - mail/srossner.nsf from CN=serv01/O=singultus
[002723:000044-00007F961B060700] REPAIR: Job-00005.3 *Post Process* - Repaired - File mail/srossner.nsf CN=serv01/O=singultus!mail/srossner.nsf [/local/notesdata/mail/R8182718.TMP]
[002723:000044-00007F961B060700] Clearing DBIID 709A5D32 for DB /local/notesdata/mail/R8182718.TMP
[002723:000044-00007F961B060700] REPAIR: Job-00005.4 *Scan DAOS* - Scanning 5 DAOS objects for mail/srossner.nsf [/local/notesdata/mail/R8182718.TMP]
[002723:000044-00007F961B060700] REPAIR: Job-00005.5 *Repaired* - mail/srossner.nsf Successfully repaired
[002723:000044-00007F961B060700] REPAIR: Job-00004.3 *Repair Failed* - File mail/srossner.nsf cannot be repaired [File already exists]
 
2. Delete a NLO file from the DAOS repository
 
I delete some NLO files from the local DAOS repository. Waited a while. Nothing happened
 
I did a te daosmgr repair and got a long list of missing NLO in addition to the handful of NLO, I had deleted before
 
...
...
[003802:000034-00007F2614822700] file /local/daos/0001/D8A791BAA1ED16D90C6B126E34CDCD1250A581E0001984D0.nlo is missing and should be repaired
[003802:000034-00007F2614822700] file /local/daos/0001/60361C292FDF11D97F557D69D6134728F70579FB000CFCD0.nlo is missing and should be repaired
[003802:000034-00007F2614822700] file /local/daos/0001/9CB929D3BEFDA49B8B10B512465AFEAC593739D2002C7000.nlo is missing and should be repaired
[003802:000034-00007F2614822700] file /local/daos/0001/12A5427E3C52FB0BE2C02FC90039FE3C877061C700101D34.nlo is missing and should be repaired
[003802:000034-00007F2614822700] file /local/daos/0001/8A9C14C3B76A8CAAA335E46AFE50A953E0DB2E2D00315682.nlo is missing and should be repaired
[003802:000034-00007F2614822700] file /local/daos/0001/0DDA93052E55C07421CE09E04A561043E0AF1D7F0018FB33.nlo is missing and should be repaired
[003802:000034-00007F2614822700] DAOSMGR: REPAIR completed
 
 
Using
DEBUG_DAOS_DIAGNOSTICS=1
 
tell daosmgr LISTNLO MAP -V mail
 
I was able to identify the according database (mail/ukrausebcc.nsf) for one of the entries in that list.
 
OK, so another database would need to be repaired.
 
Next , I did
 
repair file mail/ukrausebcc.nsf
 
[002723:000009-00007F9631941700] REPAIR: 0 file(s) queued for repair
 
I assume that the repair file does not work with a NLO file, but I tried
 
repair file local/daos/0001/0DDA93052E55C07421CE09E04A561043E0AF1D7F0018FB33.nlo      
                                                                                                          
[002723:000009-00007F9631941700] REPAIR: repair call failed with error: Entry not found in index
[002723:000009-00007F9631941700] Entry not found in index
 
 
So, how can I make sure that the DAOS repository contains ALL needed files ?

[eknori]

Hier eine ergänzende Information von den Entwicklern

Code

 > So, how can I make sure that the DAOS repository contains ALL needed files ?

You can not with Domino 10.0 or 10.0.1. 
Repair of DAOS objects is limited in those versions.  
A general DAOS repair mechanism is on our list for a future release.  
If a database needs repair (because it is missing or corrupted),
then that database will be copied from a cluster mate, 
then any missing NLOs for that database will also be copied from a cluster mate.  
So, stated simply, it takes a database needing repair to trigger possible repair of DAOS 
objects, but it is limited to objects referenced by that database. 

Schade eigentlich; ich war der festen Meinung, daß das Feature vollständig implementiert ist ...