md_raid10 정지 - 가능한 원인은 무엇입니까?

md_raid10 정지 - 가능한 원인은 무엇입니까?

저는 이 동작에 대한 가능한 이유를 조사해 왔습니다.

INFO: task md1_raid10:240 blocked for more than 120 seconds.
[123491.284102]       Not tainted 4.18.20 #1
[123491.284105] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[123491.284109] md1_raid10      D    0   240      2 0x80000000
[123491.284116] Call Trace:
[123491.284132]  ? __schedule+0x421/0x8c0
[123491.284138]  ? preempt_count_add+0x67/0xb0
[123491.284144]  schedule+0x3c/0x90
[123491.284162]  md_super_wait+0x69/0xa0 [md_mod]
[123491.284173]  ? remove_wait_queue+0x60/0x60
[123491.284184]  md_update_sb.part.61+0x4ad/0x900 [md_mod]
[123491.284197]  md_check_recovery+0x310/0x530 [md_mod]
[123491.284205]  raid10d+0x64/0x15a0 [raid10]
[123491.284211]  ? __schedule+0x429/0x8c0
[123491.284216]  ? schedule+0x46/0x90
[123491.284220]  ? schedule_timeout+0x1f7/0x370
[123491.284224]  ? preempt_count_add+0x67/0xb0
[123491.284229]  ? _raw_spin_lock_irqsave+0x25/0x50
[123491.284232]  ? preempt_count_add+0x67/0xb0
[123491.284243]  ? md_thread+0x120/0x160 [md_mod]
[123491.284252]  md_thread+0x120/0x160 [md_mod]
[123491.284258]  ? remove_wait_queue+0x60/0x60
[123491.284263]  kthread+0xf8/0x130
[123491.284272]  ? md_rdev_init+0xc0/0xc0 [md_mod]
[123491.284277]  ? kthread_create_worker_on_cpu+0x70/0x70
[123491.284281]  ret_from_fork+0x22/0x40

stackexchange를 포함하여 내가 찾은 모든 것은 과도한 시스템 부하로 인해 서버 상태가 좋지 않음을 나타냅니다. 제 경우에는 새로운 Raid1+0 구성으로 4HHS를 호스팅하는 시스템에서 이런 일이 발생했습니다. 실제로 시스템은 어제 바로 설정되었으며 데이터가 거의 포함되어 있지 않았습니다. SMB 클라이언트를 통해 홈 디렉터리(파일 10개만 포함)를 나열할 때 중단이 발생합니다.

이 시스템의 디스크는 dm_crypt를 사용하여 암호화됩니다. LVM은 사용되지 않습니다.

root@stasiek1:/home/lacki# cat /proc/mdstat
Personalities : [raid10] [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] 
md1 : active raid10 sdd3[3] sdb3[1] sda3[0] sdc3[2]
      7225882624 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 1/54 pages [4KB], 65536KB chunk

md0 : active raid10 sdd2[3] sda2[0] sdc2[2] sdb2[1]
      585674752 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 3/5 pages [12KB], 65536KB chunk

unused devices: <none>


root@stasiek1:/home/lacki# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sat Dec 29 22:59:44 2018
     Raid Level : raid10
     Array Size : 585674752 (558.54 GiB 599.73 GB)
  Used Dev Size : 292837376 (279.27 GiB 299.87 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Jan 29 22:14:24 2019
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : near=2
     Chunk Size : 512K

           Name : stasiek1:0  (local to host stasiek1)
           UUID : d12a1437:ab040229:dbc0f4bf:796a97dd
         Events : 768

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync set-A   /dev/sda2
       1       8       18        1      active sync set-B   /dev/sdb2
       2       8       34        2      active sync set-A   /dev/sdc2
       3       8       50        3      active sync set-B   /dev/sdd2


root@stasiek1:/home/lacki# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Sat Dec 29 23:00:13 2018
     Raid Level : raid10
     Array Size : 7225882624 (6891.14 GiB 7399.30 GB)
  Used Dev Size : 3612941312 (3445.57 GiB 3699.65 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Jan 29 22:13:37 2019
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : near=2
     Chunk Size : 512K

           Name : stasiek1:1  (local to host stasiek1)
           UUID : bdf36256:191923e1:01254e05:8bc447c9
         Events : 7357

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync set-A   /dev/sda3
       1       8       19        1      active sync set-B   /dev/sdb3
       2       8       35        2      active sync set-A   /dev/sdc3
       3       8       51        3      active sync set-B   /dev/sdd3

시스템: 커널: 4.18. 데비안 스트레치

답변1

답변보다 댓글이 더 많은데 댓글이 너무 깁니다.

이는 커널 버그일 수 있습니다. 불행하게도 이와 같은 커널 문제는 매우 일반적입니다. 최근 예는 다음과 같습니다.MD: 장애물로 인한 raid10 정지 문제 수정.

커널 개발자가 아니고 이에 대해 자세히 알아보고 싶지 않다면 커널 버그에 대해 할 수 있는 일이 많지 않습니다. :-)

그렇다면 그것은 단지 희망/운의 문제일 뿐입니다. 이 문제가 많은 사람들에게 영향을 미치는지, 아니면 이상한 이유로 귀하에게만 영향을 미치는지에 대한 질문도 있습니다.

본인만 문제라면 커널 버그처럼 보이더라도 새 하드웨어를 새로 설치하면 문제가 "수정"될 수 있습니다. 많은 버그가 근본 원인을 제대로 파악하지 못한 채 이런 방식으로 수정됩니다(그러려면 특별한 기술과 시간이 필요하기 때문입니다...).

관련 정보