First, your ec profile output is 4+2, not 8+2:
ceph osd erasure-code-profile get my-ec-profile02
crush-device-class= crush-failure-domain=host crush-root=default jerasure-per-chunk-alignment=false k=4 m=2
But according to your health output there are 10 chunks, so 8+2 it probably is. You have to be aware that EC pools usually have a min_size of k+1, so in your case 9 chunks are required to keep the pool active. You can only delete one OSD at a time. You can temporarily reduce min_size to k, but don't forget to set it back to k+1. It's a safety switch, and it's there for a reason. Zitat von 苏察哈尔灿 <2644294460@qq.com>:
I am deleting two OSD nodes on a node, and ceph health detail indicates that there are 15 pgs inactive, as follows: [WRN] PG_AVAILABILITY: Reduced data availability: 15 pgs inactive pg 37.4 is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [NONE,40,38,88,0,22,62,32,NONE,21] pg 37.a is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [38,103,NONE,57,20,NONE,63,51,8,18] pg 37.c is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [58,7,18,38,52,101,80,NONE,62,NONE] pg 37.62 is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [67,101,NONE,57,62,NONE,7,26,14,20] pg 37.97 is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [35,19,NONE,13,58,17,20,6,25,NONE] pg 37.9d is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [103,22,NONE,63,NONE,34,45,56,90,14] pg 37.b4 is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [61,NONE,NONE,46,86,60,9,66,21,35] pg 37.136 is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [10,NONE,24,78,48,89,NONE,56,8,51] pg 37.13a is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [71,33,NONE,14,32,27,NONE,5,25,57] pg 37.149 is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [6,69,65,84,27,25,NONE,0,14,NONE] pg 37.15c is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [103,66,6,23,NONE,NONE,61,45,8,42] pg 37.16d is stuck inactive for 113m, current state recovering+undersized+remapped+peered, last acting [79,68,26,66,58,NONE,52,8,NONE,60] pg 37.17b is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [80,47,27,14,24,NONE,67,35,NONE,5] pg 37.1d0 is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [0,76,68,57,NONE,10,48,85,101,NONE] pg 37.1ea is stuck inactive for 113m, current state recovery_wait+undersized+degraded+remapped+peered, last acting [28,24,52,20,10,43,56,NONE,NONE,80]
My pool is used using 8+2 erasure-code configuration: ceph osd erasure-code-profile get my-ec-profile02
crush-device-class= crush-failure-domain=host crush-root=default jerasure-per-chunk-alignment=false k=4 m=2 plugin=jerasure technique=reed_sol_van w=8
In theory, it should be possible to access the corresponding pool, but in fact, the client cannot access normally, or it will be stuck in the middle of the access. Why?
Then, when using the command "rados -p cephfs-backup.data-ec ls" to display the pool object, it also stuck
10000000e74.00000cd8 1000000080f.00004436 10000000e3d.000012e3 10000000e50.000018a2 1000000081b.00005b22 100000003d3.0000777a 100000003d7.00003c64 Cursor motionless
thank you! _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io