뭔가가 내 하드 드라이브를 계속 닳게 하지만(초당 몇 킬로바이트) 원인을 알 수 없는 것 같습니다.
내 구성: 4개의 회전 플래터(/dev/sd[cdef])가 raid5 배열로 조립된 다음 bcache가 모든 것을 캐시하도록 설정됩니다(cache_mode=writeback, ential_cutoff=0). bcache 볼륨 위에 lvm을 설정했습니다.
sda와 sdb는 SSD입니다. sdc, sdd, sde 및 sdf는 회전 디스크이며 mdadm -> bcache -> lvm -> dm-*의 기반입니다.
따라서 이것은 (두 번째 인쇄의) 출력입니다 iostat -x -d 30.
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,77 0,97 0,77 12,40 6,13 21,38 0,00 0,23 0,00 0,52 0,23 0,04
sdb 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdc 0,03 1,60 0,13 4,50 0,67 17,63 7,90 0,05 11,54 15,00 11,44 11,17 5,17
sdd 1,60 0,30 0,43 4,83 8,13 13,77 8,32 0,06 11,27 0,00 12,28 11,04 5,81
sde 1,63 0,00 0,57 4,07 8,80 9,50 7,90 0,05 10,99 0,47 12,46 10,73 4,97
sdf 0,00 1,90 0,00 5,27 0,00 21,90 8,32 0,04 8,53 0,00 8,53 8,35 4,40
md0 0,00 0,00 0,00 0,97 0,00 12,40 25,66 0,00 0,00 0,00 0,00 0,00 0,00
bcache0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-4 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-5 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-6 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-7 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-9 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
이 iostat 출력에서 이상하게 보이는 것은 bcache가 전혀 건드리지 않았기 때문에 논리 볼륨에 활동이 없다고 가정한다는 것입니다.
iotop이 주제에 대한 언급도 없습니다. 디스크에서 실행 중인 응용 프로그램이 보고되지 않으므로 일부 시스템 데몬/서비스임에 틀림없습니다.
md0볼륨에 일부 활동이 표시되지만 논리 볼륨에 쓰기가 없으므로 이것이 어떻게 가능합니까? bcache뭔가 유지보수 작업을 하고 있는 것 같죠 ? 하지만 매초? ? ?
마지막으로 sdc의 일부 활동 - sdf는 실제로 md0의 활동과 일치하지 않습니다. 또한 모든 디스크에 걸쳐 비대칭이므로 mdadm 기반도 아닌 것 같습니다.
편집: meuh의 제안에 따라 iosnoop출력은 다음과 같습니다.
Tracing block I/O. Ctrl-C to end.
COMM PID TYPE DEV BLOCK BYTES LATms
md0_raid5 281 FFS 8,80 18446744073709551615 0 0.04
md0_raid5 281 FFS 8,32 18446744073709551615 0 0.11
md0_raid5 281 FFS 8,64 18446744073709551615 0 0.10
md0_raid5 281 FFS 8,48 18446744073709551615 0 0.10
<idle> 0 WS 8,80 16 4096 0.08
kworker/3:1H 276 WS 8,32 16 4096 0.10
kworker/3:1H 276 WS 8,64 16 4096 0.10
kworker/3:1H 276 WS 8,48 16 4096 0.09
<idle> 0 FFS 8,80 18446744073709551615 0 8.45
<idle> 0 FFS 8,64 18446744073709551615 0 17.42
<idle> 0 FFS 8,32 18446744073709551615 0 19.36
<idle> 0 FFS 8,48 18446744073709551615 0 20.68
md0_raid5 281 FFS 8,32 18446744073709551615 0 0.11
md0_raid5 281 FFS 8,80 18446744073709551615 0 0.10
md0_raid5 281 FFS 8,64 18446744073709551615 0 0.13
md0_raid5 281 FFS 8,48 18446744073709551615 0 0.14
<idle> 0 WS 8,80 8 512 0.06
<idle> 0 WS 8,32 8 512 0.10
<idle> 0 WS 8,64 8 512 0.08
ksoftirqd/3 28 WS 8,48 8 512 0.08
cat 14719 FFS 8,80 18446744073709551615 0 12.42
cat 14719 FFS 8,64 18446744073709551615 0 17.27
cat 14719 FFS 8,32 18446744073709551615 0 19.21
cat 14719 FFS 8,48 18446744073709551615 0 20.52
여기에 나열된 모든 장치는 회전하는 플래터입니다.
Edit2: Frostschutz의 제안에 따라 block_dump를 활성화한 후 시스템 로그에서 발췌한 내용은 다음과 같습니다.
[40723.578347] md0_raid5(281): WRITE block 8 on sdc (1 sectors)
[40723.578359] md0_raid5(281): WRITE block 8 on sde (1 sectors)
[40723.578363] md0_raid5(281): WRITE block 8 on sdd (1 sectors)
[40723.578367] md0_raid5(281): WRITE block 8 on sdf (1 sectors)
[40723.824546] md0_raid5(281): WRITE block 16 on sdc (8 sectors)
[40723.824560] md0_raid5(281): WRITE block 16 on sde (8 sectors)
[40723.824566] md0_raid5(281): WRITE block 16 on sdd (8 sectors)
[40723.824570] md0_raid5(281): WRITE block 16 on sdf (8 sectors)
mdadm그렇다면 범인은 (아마도) 슈퍼블록 오프셋을 지속적으로 쓰는 것인 것 같습니다 .
추가 조사를 통해 mdadm -E /dev/sdc매초마다 다른 체크섬이 보고된다는 사실이 확인되었습니다. 이벤트 수는 일반적으로 고정된 상태로 유지되지만 드라이브를 자주 다시 확인하면 가끔씩 상태가 "청소"에서 "활성"으로 변경되고 이러한 확인 중에 이벤트 수가 다른 것보다 하나 더 높아집니다.
그렇다면 무슨 일이 일어나고 있는지에 대한 논리적인 설명이 있나요? 아니면 내 디스크에 무슨 일이 일어나고 있는지 더 자세히 알아보기 위해 할 수 있는 일이 있나요?
답변1
meuh &frostschutz 덕분에 문제가 있는 프로세스를 식별할 수 있었습니다. mdadm이 어레이에서 일부 동기화 후 작업을 수행하는 것 같습니다(며칠 전에 RAID-5 어레이의 드라이브를 교체했습니다).
실제로 드라이브를 교체한 지 며칠 만에 작동이 멈췄습니다. 흥미롭게도 유일한 I/O가 슈퍼블록 영역에 쓰는 것이기 때문에 이 작업을 수행합니다. 나는 현재 자격이 없는 코드를 살펴보아야만 권위 있는 답변을 제공할 수 있다고 생각합니다.
편집: 방금 10GB의 데이터 몇 개를 어레이에 복사했고 연삭이 다시 시작되었습니다. 그럼 post sync가 아니라 post 임의 쓰기가 되는군요...