최근에 RAID 5 어레이에서 두 개의 하드 드라이브가 충돌했는데 모니터링을 구성하지 않았기 때문에 한동안 하나가 충돌했다는 사실을 알아차리지 못했습니다. 그래서 모든 것을 폐기하고 처음부터 다시 시작하기로 결정했습니다.
모든 하드웨어는 이전과 동일합니다. 단, 어레이에 이전보다 적은 수의 드라이브가 있고 8개가 아닌 3개의 더 큰 드라이브가 있습니다. 또한 레거시 부팅 옵션을 사용하는 대신 Arch Linux를 UEFI로 설치했는데 이것이 어떤 영향을 미치는지 확실하지 않습니다. .
적절한 mdadm 모니터링/알림 및 일일 단기 SMART 테스트(및 주간 장기 테스트)를 사용하여 Arch Linux를 다시 설치했습니다.
그러나 Arch Linux를 다시 설치한 이후로 일반적으로 가동 시간이 48시간 이상 지난 후 임의의 커널 패닉이 발생했습니다.
나는 커널 패닉의 사진을 찍었습니다.
지금 보니 mdadm과 관련이 있는 것 같습니다.
내 mdadm 구성은 다음과 같습니다.
Personalities : [raid1] [raid6] [raid5] [raid4]
md0 : active raid1 sda1[0] sdb1[1]
524224 blocks super 1.0 [2/2] [UU]
md1 : active raid1 sda3[0] sdb3[1]
1950761024 blocks super 1.2 [2/2] [UU]
bitmap: 5/15 pages [20KB], 65536KB chunk
md2 : active raid5 sde1[3] sdc1[0] sdd1[1]
5796265984 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
bitmap: 0/22 pages [0KB], 65536KB chunk
unused devices: <none>
mkinitcpio.conf의 관련 줄:
HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck"
저는 현재 Linux akatosh 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015 x86_64 GNU/Linux를 사용하고 있습니다.
RAM을 다시 장착하려고 했지만 Arch Linux를 다시 설치하기 전에는 RAM 문제가 발생하지 않았으므로 RAM 문제인지 의심됩니다.
연구에서 발견한 mdadm과 관련된 대부분의 커널 패닉 문제는 부팅 시 발생했습니다. 문제가 무엇인지 아는 사람이 있나요?
편집하다: 이는 4.1.4 또는 4.1.5에서 소개된 알려진 버그인 것 같습니다.https://bugzilla.redhat.com/show_bug.cgi?id=1255509
테스트를 통해 4.2.0으로 업데이트하려고 노력하고 더 많은 정보로 이 게시물을 업데이트하겠습니다.
답변1
이는 다음과 함께 도입된 알려진 버그입니다.
edbe83ab4c27 md/raid5: allow the stripe_cache to grow and shrink.
더 많은 정보를 얻을 수 있습니다이 공식 버그 보고서에서 "버그 1255509 - 버그: ffffffffffffffd8에서 커널 페이징 요청을 처리할 수 없습니다."에서 발견되었습니다.
해결책은 4.2.0으로 업그레이드하는 것입니다.