Hai uns días, nun cliente produciuse un reinicio abrupto dun clúster GI 12.1.0.2 por problemas hardware relacionados co acceso á SAN a través dunha rede 10GbE. O problema repetiuse no outro nodo de madrugada ó comezar o volcado programado Data Pump das bases de datos. Sen coñecer o detalle do problema, estaba relacionado coa saturación dun porto nun chasis de blades que, a través de algún mecanismo forzaba o peche do porto e o consecuente corte de conectividade e reinicio do servidor. Debido á coincidencia do inicio dos exports, os administradores de sistemas analizaron o acceso a cabina, vendo que a saturación era debida, no segundo dos reinicios, a actividade sobre o filesystem ACFS que xa en ocasións anteriores tiveramos observado. Esta actividade era xerada polo proceso automático de resilvering de ACFS.
Que é resilvering?
Trátase dun concepto asociado á reconstrución dun mirror de disco. A palabra é moi propia xa que resilver deriva da acción de volver a tratar con prata as zonas deterioradas dun espello (ou mirror) real de cristal. Esta capa de prata (ou outro material como o aluminio) é a que converte o cristal nun espello, e a que, á medida que se deteriora, fai que aparezan “erros” e transparencias no mesmo.
Cando se produce un problema nun raid, como a perda dun dos discos que o compoñen, o proceso de resilvering é o que, unha vez incorporado o novo disco, restablece a sincronización de datos coa nova configuración. É mais habitual atopar este concepto como rebuild ou resync, pero resilver é empregado tamén por ZFS, concepto similar ó de ACFS dende o punto de vista de que se trata dunha combinación de filesystem e volume manager. ZFS foi desenvolto por Sun Microsystems antes da súa adquisición por Oracle. Entre as propiedades de ZFS, podemos ver:
The features of ZFS include protection against data corruption, support for high storage capacities, efficient data compression, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs.
Algunhas son características que atopamos tamén en ACFS.
Por que se fai resilvering?
Neste caso, o proceso de resilvering estase a producir sobre un filesystem de case 2TiBs de tamaño. O diskgroup sobre o que se creou o volume ADVM e o filesystem ACFS está creado sobre LUNs que na cabina teñen unha política bastante restritiva a nivel de QoS, o que estaba a provocar que este proceso precisase mais de 10h para completarse.
En ASM / ACFS / ADVM, non é moita a información que puiden atopar sobre este procedemento. A maior parte da información en MOS está relacionada con bugs, como por exemplo o comentado na nota 2071755.1 na que se describe un problema de alto consumo de CPU pola actividade do proceso asmResilver1. Existe mais información sobre o proceso de resilver relacionado cos sistemas Exadata ou ODA, aínda que non acaba de ser un proceso moi específico en canto á súa implementación xeral a nivel de ACFS. Neste punto, recomendo a lectura de esta entrada e esta outra do blog de Erman Arslan.
Moi ilustrativa a definición dos roles dos procesos asmresilver1 e asmresilver2 que actúan baixo condicionantes diferentes. Segundo esta información, asmResilver1 entra en xogo ante escenarios de crash como a caída e recuperación dunha instancia ASM, e verifica se é precisa a recuperación dalgún bloque no mirror, encargándose de facelo en caso de ser asi. asmResilver2 entra en xogo cando se produce unha reconfiguración de clúster, por exemplo tras o reinicio dun servidor do RAC. Este proceso verifica se o volume precisa algunha operación de recuperación.
O proceso de resilvering é propio de ADVM e é diferente do proceso de rebalanceo propio de ASM que podemos ver en calquera diskgroup, incluídos aqueles que conteñen volumes ADVM. En sistemas Linux, podemos ver reflectida a súa actividade no ficheiro var/log/messages, onde o driver ADVM envorca a súa saída:
ADVMK-0010: Mirror recovery for volume VOLACFS in diskgroup ACFS started
ADVM indicará cando se produce unha reconfiguración de clúster que forza o resilver do volume. Do escenario tratado, no messages aparecen as seguintes entradas, o inicio da reconfiguración, e o evento de fin de reconfiguración que recibe de cada un dos nodos.
ADVMK-0013: Cluster reconfiguration started. ADVMK-0014: Cluster reconfiguration completed. ADVMK-0014: Cluster reconfiguration completed.
Procesos involucrados no resilvering
No noso exemplo, vemos que tras a caída forzada dun nodo, atopamos tamén dous procesos, aínda que denominados asmResilver e asmResilver2 que son executado como usuario root. O primeiro é nesta ocasión o responsable da validación dos datos, e o segundo dos metadatos DRL para a xestión da redundancia. Os procesos execútanse no nodo responsable do resilver en curso, non existindo ningún proceso deste tipo no outro nodo nin sequera cando se recupera e reincorpora ó clúster. A nivel de ASM, non cheguei a atopar ningunha operación dentro de gv$asm_operation, pese a que contempla a opción de amosar tarefa de resilvering, pero é unha casuística específica de Exadata cando se habilita WriteBack FlashCache:
RESILVER– This value appears in Oracle Exadata environments when WriteBack FlashCache is enabled
Tampouco identifiquei en ningún dos casos ningún ficheiro de traza específico asociado ó proceso de resilvering. Si parece ter relación o número de procesos ADVM en execución, moi superior no nodo que está facendo o resilvering:
[root@nodo1 ~]# ps -ef | grep ADVM root 11786 2 0 12:11 ? 00:00:00 [ADVM] root 11787 2 0 12:11 ? 00:00:00 [ADVM] root 25444 2 0 Apr26 ? 00:00:02 [ADVM] root 29858 2 0 12:19 ? 00:00:00 [ADVM] [oracle@nodo2 ~]$ ps -ef | grep ADVM root 12347 2 3 12:45 ? 00:00:46 [ADVM] root 23453 2 2 12:47 ? 00:00:35 [ADVM] root 23454 2 3 12:47 ? 00:00:44 [ADVM] root 23470 2 2 12:47 ? 00:00:39 [ADVM] root 23472 2 3 12:47 ? 00:00:44 [ADVM] root 23473 2 2 12:47 ? 00:00:29 [ADVM] root 23485 2 2 12:47 ? 00:00:36 [ADVM] root 23486 2 1 12:47 ? 00:00:27 [ADVM] root 23487 2 1 12:47 ? 00:00:27 [ADVM] root 23505 2 2 12:47 ? 00:00:33 [ADVM] root 23506 2 2 12:47 ? 00:00:33 [ADVM] root 23508 2 3 12:47 ? 00:00:44 [ADVM] root 23509 2 2 12:47 ? 00:00:42 [ADVM] root 23511 2 2 12:47 ? 00:00:38 [ADVM]
Como veremos mais adiante, estes procesos ADVM son aparentemente procesos denominados UsmMonitor.
Onde atopar información sobre o proceso de resilvering
Neste punto, se acudimos á nota MOS , podemos ver o xeito de amosar o log correspondente a AVM, ben a través da liña de comandos, ben a través do ficheiro /proc/oks/log. Este ficheiro é a traza en memoria do driver OKS (Oracle Kernel Service), un dos 3 drivers kernel que compoñen ACFS, xunto con ACFS e ADVM, e que Oracle agrupa no que se denomina USM kernel drivers. Podemos ver os tres drivers no directorio usm dentro dos módulos do kernel.
[root@nodo acfs]# ls -la /lib/modules/3.10.0-229.1.2.el7.x86_64/extra/usm/ total 65132 drwxr-xr-x 2 root root 4096 May 4 2016 . drwxr-xr-x 3 root root 4096 May 4 2016 .. -rw-r--r-- 1 root root 45106765 May 4 2016 oracleacfs.ko -rw-r--r-- 1 root root 12644673 May 4 2016 oracleadvm.ko -rw-r--r-- 1 root root 8926957 May 4 2016 oracleoks.ko
Dende a versión 11.2.0.3, este log está tamén dispoñible en disco, podendo acceder a el a través de $GRID_BASE/crsdata/<hostname>/acfs en 12c ou $GRID_HOME/log/<hostname>/acfs/kernel en 11gR2. Aquí si podemos atopar información do proceso de Resilver:
V 4294808.419/170427124724 asmResilver[23471] Asm_resilverVolume: EXPORT.volexpdp-440: resilver start V 4294808.419 asmResilver[23471] Asm_startResilveringOps: EXPORT.volexpdp-440: initial broadcast recovProg=zero K 4294825.656/170427124741 UsmMonitor[12350] Ks_reapZombies/ADVM free cb 0xffff880b0351a200/asmResilver ncbs=1 nops=1 runTm=17.651170 completions=0 completions Tm=0.000000 V 4298071.340 asmResilver[23471] Asm_waitResilveringDone: EXPORT.volexpdp-440: setting valb 0x18446744073709551614 V 4298071.340/170427134147 asmResilver[23471] Asm_freeResilverInfo: EXPORT.volexpdp-440: 2596096 regions 166150144 I/Os, 3263 secs
Adicionalmente á información de inicio e fin que podemos obter en /var/log/messages, aquí podemos ver o resumo de información en canto a tempo e número de IOs xeradas no proceso. Revisando este interesante log, podemos obter mais información sobre que está acontecendo e por que este proceso está en marcha.
Por outro lado, a versión 12.1.0.2 da Grid Infrastructure introduce a funcionalidade de binary logging para os drivers USM. Na mesma ruta onde se xeran os logs oks, temos logs binarios non editables en texto que poden ser útiles na apertura de casos con soporte. Tamén aparece un ficheiro de eventos específico, onde tamén se rexistran, ademais de moitos outros, os eventos de resilvering que vemos no messages. De feito, é un ficheiro onde consultar de xeito doado o histórico (cando menos recente) de eventos de resilvering que estamos buscando.
[root@nodo2 acfs]# grep -i resilver event.log 2016-05-18 10:17:53.446: asmResilver2[9027] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-05-18 10:17:53.743: asmResilver2[9027] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-06-01 14:41:55.352: asmResilver2[11555] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-06-01 14:41:55.412: asmResilver2[11555] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-06-02 15:27:39.535: asmResilver[6687] Volume ACFS.volacfscws-300: Mirror recovery start 2016-06-02 15:27:39.543: asmResilver[6687] Volume ACFS.volacfscws-300: Mirror recovery done 2016-06-02 15:27:39.778: asmResilver[8226] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-06-02 15:27:39.844: asmResilver[8226] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-06-03 19:25:47.052: asmResilver2[1940] Volume ACFS.volacfscws-300: Mirror recovery start 2016-06-03 19:25:47.055: asmResilver2[1940] Volume ACFS.volacfscws-300: Mirror recovery done 2016-06-03 19:25:47.232: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-06-03 19:25:47.333: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-06-07 11:33:32.637: asmResilver2[5345] Volume ACFS.volacfscws-300: Mirror recovery start 2016-06-07 11:33:32.640: asmResilver2[5345] Volume ACFS.volacfscws-300: Mirror recovery done 2016-06-07 11:33:32.857: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-06-07 11:33:32.961: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-06-07 16:50:33.263: asmResilver2[11470] Volume ACFS.volacfscws-300: Mirror recovery start 2016-06-07 16:50:33.267: asmResilver2[11470] Volume ACFS.volacfscws-300: Mirror recovery done 2016-06-07 16:50:33.671: asmResilver2[9805] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-06-07 16:50:33.777: asmResilver2[9805] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-06-07 20:22:10.277: asmResilver2[9843] Volume ACFS.volacfscws-300: Mirror recovery start 2016-06-07 20:22:10.281: asmResilver2[9843] Volume ACFS.volacfscws-300: Mirror recovery done 2016-06-07 20:22:10.410: asmResilver2[9842] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-06-07 20:22:10.478: asmResilver2[9842] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-09-03 18:48:29.779: asmResilver2[4253] Volume ACFS.volacfscws-300: Mirror recovery start 2016-09-03 18:48:30.173: asmResilver2[4252] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-09-03 18:49:10.761: asmResilver2[4253] Volume ACFS.volacfscws-300: Mirror recovery done 2016-09-03 18:53:19.050: asmResilver2[4252] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2016-09-03 18:53:19.242: asmResilver2[24255] Volume EXPORTORA.volexpdp-226: Mirror recovery start 2016-09-03 20:54:09.219: asmResilver2[24255] Volume EXPORTORA.volexpdp-226: Mirror recovery done 2017-04-11 10:11:23.334: asmResilver2[30137] Volume ACFS.volacfscws-300: Mirror recovery start 2017-04-11 10:11:23.989: asmResilver2[612] Volume EXPORT.volexpdp-440: Mirror recovery start 2017-04-11 10:11:48.686: asmResilver2[30137] Volume ACFS.volacfscws-300: Mirror recovery done 2017-04-11 10:16:51.762: asmResilver2[612] Volume EXPORT.volexpdp-440: Mirror recovery done 2017-04-11 10:16:51.966: asmResilver2[612] Volume EXPORT.volexpdp-440: Mirror recovery start 2017-04-12 12:40:15.534: asmResilver[24516] Volume EXPORT.volexpdp-440: Mirror recovery start 2017-04-12 12:46:31.157: asmResilver[24516] Volume EXPORT.volexpdp-440: Mirror recovery done 2017-04-12 15:16:12.374: asmResilver[24573] Volume EXPORT.volexpdp-440: Mirror recovery start 2017-04-12 16:49:11.462: asmResilver[24573] Volume EXPORT.volexpdp-440: Mirror recovery done 2017-04-27 12:47:24.115: asmResilver[23453] Volume ACFS.volacfscws-300: Mirror recovery start 2017-04-27 12:47:24.530: asmResilver[23471] Volume EXPORT.volexpdp-440: Mirror recovery start 2017-04-27 12:47:41.767: asmResilver[23453] Volume ACFS.volacfscws-300: Mirror recovery done 2017-04-27 13:41:47.451: asmResilver[23471] Volume EXPORT.volexpdp-440: Mirror recovery done
DRL
O proceso de resilvering é un proceso de reconstrución de mirror baseada en DRL (Dirty Region Logging), de emprego común en outros sistemas (por exemplo Veritas Volume Manager) e que aplica un principio similar ó journaling habitual en sistemas de ficheiros como por exemplo ext4. No propio log de ADVM vemos que se referencia este concepto tanto na nomenclatura como na funcionalidade. Así, cando arrinca o volume, vemos que se fai unha verificación dos dirty bits, e ademais identificamos que os 1,8TiBs de datos están representados nun bitmap de 17MiBs e un total de 7.167.232 bits.
V 4294808.039 multipathd[720] AsmVolStateOpen: EXPORT.volexpdp-440: checking for recovery, DRL segment: 0, DRL size: 17M V 4294808.419 multipathd[720] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 2596096/7167232 36%
Regions
No enlace de Veritas vemos unha funcionalidade na que se emprega un mapa de bits para reprensentar o almacenamento do volume e identificar as rexións que están marcadas a nivel de mirror como “dirty”. Un bit do mapa representa unha rexión, no caso de Veritas, 1024 sectores. No caso de ADVM atopamos no mesmo log que o tamaño de cada rexión é de 512 bloques.
V 4294808.039 multipathd[720] Asm_drlVolAttach: <strong>512 blks/region</strong>, 219 pgs, -625344512 blks/vol, 7167231 voldEndB 128 pgNrpcr
Monitorizar un proceso de resilvering
Con unha operación de cat ou tail sobre /proc/oks/log ou sobre o acfs.log.0 a partires de 12.1.0.2, podemos identificar a porcentaxe de rexións dirty pendentes de procesar por parte do proceso asmResilver1. Filtrando pola cadea Asm_logBits e polo volume que nos interesa, podemos ver a súa evolución:
[root@nodo2 ~]# grep Asm_logBits /proc/oks/log | grep volexpdp-440 V 4294808.419 multipathd[720] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 2596096/7167232 36% V 4295108.276 UsmRslvrUpd:PRO[23454] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 344814079, dirty bits = 2365134/7167232 32% V 4295408.286 UsmRslvrUpd:PRO[23485] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 664690175, dirty bits = 2120532/7167232 29% V 4295708.312 UsmRslvrUpd:PRO[23509] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1003418111, dirty bits = 1892618/7167232 26% V 4296008.304 UsmRslvrUpd:PRO[23473] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1299421183, dirty bits = 1664439/7167232 23% V 4296308.250 UsmRslvrUpd:PRO[23453] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1622847999, dirty bits = 1420604/7167232 19% V 4296608.332 UsmRslvrUpd:PRO[23511] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1976684031, dirty bits = 1181212/7167232 16% V 4296908.305 UsmRslvrUpd:PRO[23506] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 2339923967, dirty bits = 931023/7167232 12% V 4297208.364 UsmRslvrUpd:PRO[23505] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 2677802495, dirty bits = 684544/7167232 9% V 4297508.303 UsmRslvrUpd:PRO[23453] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 3034652671, dirty bits = 441843/7167232 6% V 4297808.358 UsmRslvrUpd:PRO[23511] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 3349218815, dirty bits = 217472/7167232 3%
Unha vez completado este proceso, é lanzado asmResilver2, empregando un proceso por cada volume ACFS montado. Este proceso, moito mais rápido que o resilver de datos, fai unha verificación e corrección de problemas nos metadatos DRL para o mantemento do mirror. Podemos ver a súa actividade no mesmo log:
V 4298172.073 asmResilver2[23505] Asm_acqRecovery: EXPORT.volexpdp-440: rsid1=1b80101 rsid2=0 V 4298172.073 asmResilver2[23505] Asm_acqRecovery: EXPORT.volexpdp-440: value block INVALID V 4298172.073 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 1 V 4298172.073 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: odlm_lock returned 36 V 4298172.073 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 2 V 4298172.082 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 2 is clean V 4298172.082 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 3 V 4298172.086 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 3 is clean V 4298172.086 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 4 V 4298172.090 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 4 is clean V 4298172.090 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 5 V 4298172.094 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 5 is clean V 4298172.094 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 6 V 4298172.104 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 6 is clean V 4298172.104 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 7 V 4298172.111 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 7 is clean V 4298172.111 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 8 V 4298172.118 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 8 is clean V 4298172.118 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 9 V 4298172.122 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 9 is clean V 4298172.122 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 10 V 4298172.128 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 10 is clean V 4298172.128 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 11 V 4298172.132 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 11 is clean V 4298172.132 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 12 V 4298172.141 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 12 is clean V 4298172.141 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 13 V 4298172.150 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 13 is clean V 4298172.150 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 14 V 4298172.156 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 14 is clean V 4298172.156 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 15 V 4298172.160 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 15 is clean V 4298172.160 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 16 V 4298172.165 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 16 is clean V 4298172.213 asmResilver2[23505] Asm_startRecovery: EXPORT.volexpdp-440: is clean, no rcvy needed V 4298172.215 asmResilver2[23505] Asm_startRecovery: EXPORT.volexpdp-440: mirror recovery thread exiting
Afecta unha operación de resilver a todo o volume ACFS?
Para mín, unha das principais dúbidas sobre este proceso era saber se cada vez que se produción unha caída abrupta se facía unha reconstrucción completa do mirror, algo que non parecía ter sentido. Tras a revisións destes logs, queda claro que non, que depende da cantidade de rexións marcadas como dirty cando comeza o proceso. Revisando o histórico de probas e caídas neste nodo, vemos que é bastante dispar, xerando diferentes cargas de IO (pode que o grep empregado non sexa exhaustivo!):
[root@nodo1 acfs]# grep Asm_logBits acfs.log.0 | grep multipathd V 4294772.311 multipathd[689] Asm_logBits: EXPORTORA.volexpdp-226: Asm_buildRecovMap: recovProg -1, dirty bits = 134144/7167232 1% V 4294777.747 multipathd[691] Asm_logBits: EXPORTORA.volexpdp-226: Asm_buildRecovMap: recovProg -1, dirty bits = 0/7167232 0% [root@nodo2 acfs]# grep Asm_logBits acfs.log.0 | grep multipathd V 4302370.602 multipathd[694] Asm_logBits: EXPORTORA.volexpdp-226: Asm_buildRecovMap: recovProg -1, dirty bits = 0/7167232 0% V 4294799.421 multipathd[703] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 5164001/7167232 72% V 4294808.419 multipathd[720] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 2596096/7167232 36%
Polo tanto, unha caída dun volume ACFS non sempre xerará a mesma actividade de IO durante o seu proceso de resilvering, dependendo da cantidade de rexións dirty que atope o proceso de DRL.
V 4294808.039 multipathd[720] AsmVolStateOpen: EXPORT.volexpdp-440: checking for recovery, DRL segment: 0, DRL size: 17M V 4294808.050 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 1 is clean <strong>V 4294808.057 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 2 is dirty</strong> V 4294808.109 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 3 is clean V 4294808.115 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 4 is clean V 4294808.121 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 5 is clean V 4294808.130 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 6 is clean V 4294808.138 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 7 is clean V 4294808.143 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 8 is clean V 4294808.150 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 9 is clean V 4294808.154 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 10 is clean V 4294808.162 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 11 is clean V 4294808.167 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 12 is clean V 4294808.170 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 13 is clean V 4294808.170 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 14 is clean V 4294808.184 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 15 is clean V 4294808.192 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 16 is clean
Maridaxe
Se falamos de mirrors, o primeiro que ven á cabeza é a ese Tommy que medra traumatizado mirando sempre a un espello, e a súa nai berrando ese “Go to the mirror!“. Look at him in the mirror dreaming, what is happening in his head?
