blk_update_request: I/O error, dev, sector

증상

journalctl -xe 로 로그를 확인했을때 빨간글씨로 아래와 같은 문구를 확인할 수 있다.

Jan 27 13:58:41 gpu3 kernel: blk_update_request: I/O error, dev sdb, sector 8447363480 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 27 13:58:41 gpu3 kernel: Buffer I/O error on dev sdb1, logical block 1055920179, async page read
...
Jan 27 13:58:41 gpu3 systemd[1]: Failed to start File System Check on /dev/disk/by-uuid/68c995a8-1115-45be-9b8b-31d971ccb3f6
...

원인

하드디스크 고장이 원인이다.

해결방안

물리적인 문제로, 소프트웨어적인 방법으로 해결할 수 없다. 해당 서버를 사용하기 위해서는 마운트를 해제하는 방법밖에 없다. 아래의 명령어를 사용하여 /etc/fstab 파일을 열어서 문제가 있는 장치를 마운트하는 명령어를 주석처리한 뒤 재부팅하면 문제가 해결된다.

vim /etc/fstab
# remove or comment out errornous block device with the uuid
reboot now

 

 

사용중인 시스템에 HDD 관련 커널에러가 발생하였다.

보통 여러가지 이유가 많지만, 이런 에러가 생기면 그냥 AS 보낸다.

그런데, 이번에는 디스크 관리를 보니 배드섹터 1 개 라고 나온다. 애매하네...
당장 시스템 교체할 하드가 마땅치 않아, AS 보내기전 잠시라도 계속 사용해야 하는 상황.

배드섹터를 기록(?)해서 에러가 발생하지 않도록 하고자 한다.

커널 에러 메세지는 이런식이다. (에러 종류에 따라 , 메시지가 다르다 )

[348303.307873] ata4: EH complete
[348305.814497] ata4.00: exception Emask 0x0 SAct 0x1000000 SErr 0x0 action 0x0
[348305.814503] ata4.00: irq_stat 0x40000008
[348305.814508] ata4.00: failed command: READ FPDMA QUEUED
[348305.814517] ata4.00: cmd 60/08:c0:78:3b:76/00:00:31:01:00/40 tag 24 ncq 4096 in
                         res 41/40:00:78:3b:76/00:00:31:01:00/40 Emask 0x409 (media error) <F>
[348305.814521] ata4.00: status: { DRDY ERR }
[348305.814524] ata4.00: error: { UNC }
[348305.815611] ata4.00: configured for UDMA/133
[348305.815625] sd 3:0:0:0: [sdc] tag#24 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[348305.815630] sd 3:0:0:0: [sdc] tag#24 Sense Key : Medium Error [current] [descriptor] 
[348305.815635] sd 3:0:0:0: [sdc] tag#24 Add. Sense: Unrecovered read error - auto reallocate failed
[348305.815639] sd 3:0:0:0: [sdc] tag#24 CDB: Read(16) 88 00 00 00 00 01 31 76 3b 78 00 00 00 08 00 00
[348305.815643] blk_update_request: I/O error, dev sdc, sector 5124799352

눈에 띄는 부분은 마지막줄.

blk_update_request: I/O error, dev sdc, sector 5124799352

배드 섹터가 생긴 것으로 보인다(다른 에러로 인해 나오는 경우도 있을 수 있을 듯 하다 - 입출력시 에러이니 다양한 원인이 있을 수 있음)

---

보통의 절차는 badblocks 로 배드섹터 위치를 찾고, fsck 로 배드섹터 표시를 해서 디스크사용시 해당 섹터를 건드리지 않도록 한다.

badblocks -v /dev/sdc1 > badsectors.txt

위 처럼 배드섹터 위치를 찾는다 ( /dev/sdc1 등은 본인의 HDD 명칭으로 쓰면 된다)
오래걸린다 (디스크 크기가 크면 클수록)
검색 범위를 정할 수 있는지 모르겠다. 2930265542

그 다음은 배드섹터를 파일시스템에 기록(?) 한다.

fsck.ext4 -l badsectors.txt  /dev/sdc1

fsck 명령은 본인의 파일시스템에 맞게 적절하게 바꿔준다. (fsck.ext2 , fsck.ext3 등)

이게 영구적인 해결방법은 아닐 듯 하다. 배드섹터가 계속 생길 수 있으니, AS 보내기 전까지 버텨보자.

---

추가

badblocks 가 너무 오래 걸린다. (거의 2시간 넘게 했는데, 반도 못했다. 6시간 넘게 걸릴 듯 하다 - 하드디스크 속도에 따라 차이가 있을 듯 함. 해당 HDD 는 7200 rpm )

badblocks -v /dev/sdc1 > badsectors.txt
Checking blocks 0 to 2930265542
Checking for bad blocks (read-only test): ^C

Interrupted at block 1102688832

block 범위를 정해서 다시 해본다. ( 전체가 5860533168 이다. 대략 배드섹터 위치는 5124799352 )

Disk /dev/sdc: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

위 처럼 한 블럭이 512 byte ( badblocks 의 기본값은 1024 - 그래서 0 to 2930265542 으로 나옴)
그런데, 512 로 하면 다음과 같은 메시지가 나온다.

badblocks: 정의한 자료형으로 쓰기엔 너무 큰 값 invalid end block (5860531087): must be 32-bit value

기본값 1024 로 해야겠다. 대신 뒤의 블럭을 반으로 나눠서 범위를 정해야 겠다. ( 2562399676 가 된다)
그러고 보니 기본값을 fsck 쪽과도 맞춰야 할까? 파일시스템마다 다를려나? ( 4096 이 기본값인가? 5124799352 x 0.125 = 640599919 이 된다.)

# badblocks -b 4096 -v /dev/sdc1 640600000 640590000 > badsectors.txt
Checking blocks 640590000 to 640600000
Checking for bad blocks (read-only test): done                                                 
Pass completed, 1 bad blocks found. (1/0/0 errors)
# cat badsectors.4096.txt 
640599663

뒤의 숫자는 640599919 의 대략 범위 위치를 {last block} {first block} ( 끝 / 시작 값을 약간 여유 잡고 지정한다 )
실제 블록 위치는 640599663 로 확인된다.

fsck 를 해보니.

# fsck.ext4 -l badsectors.4096.txt /dev/sdc1
e2fsck 1.42.13 (17-May-2015)
/dev/sdc1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 110625949: 640599663
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 1 inodes containing multiply-claimed blocks.)

File { ================== 에러난 파일 =================== } (inode #110625949, mod time Wed Jun 26 16:35:07 2019) 
  has 1 multiply-claimed block(s), shared with 1 file(s):
    <The bad blocks inode> (inode #1, mod time Sat Jul 27 21:54:33 2019)
Clone multiply-claimed blocks<y>? yes
Error reading block 640599663 (Attempt to read block from filesystem resulted in short read).  에러 무시<y>? yes
강제로 덮어쓰기<y>? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? no
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23517, counted=23516).
Fix<y>? yes
Free blocks count wrong for group #19549 (65535, counted=0).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdc1: ********** WARNING: Filesystem still has errors **********

/dev/sdc1: 36792/183148544 files (0.0% non-contiguous), 632810807/732566385 blocks

위에서 Clone multiply-claimed blocks? yes => 이 부분을 그냥 n 로 건너뛰는게 좋다. 어차피 에러로 복사(clone) 실패 하는 듯 함.

일단 위와 같이 조치했는데, 잘 된 것인지는 좀더 체크해봐야 겠다. ( 특히 block 의 위치가 맞게 처리된 것인지... )

 

Linux - Console Error: "blk_update_request: I/O error, dev fd0, sector 0" (4041456)

• 제목 : Linux - Console Error: "blk_update_request: I/O error, dev fd0, sector 0"
• 설명
• After installing the AppAssure / Rapid Recovery Linux agent, you may see the following message in your server console or your kernel logs:"[302691.504544] end_request: I/O error, dev fd0, sector 0"
• "[708.684636] blk_update_request: I/O error, dev fd0, sector 0"
• 원인
• This is caused by AppAssure / Rapid Recovery, polling for supported devices to protect in the background and incidentally polls the floppy disk drive. The floppy drive is automatically added in many cases, to virtual machines weather you specify to add it or not.Also, it should be noted that this will not affect the integrity of the AppAssure or Rapid Recovery recovery points.
• Since the floppy device is not supported for protection via AppAssure / Rapid Recovery, the device does not properly handle the poll request and throws an error.
• 해결 방안
• To resolve this issue, if you do not need a floppy disk, you can simply remove the floppy kernel module from loading on startup.CentOS/RHEL (Red Hat Enterprise Linux)2. echo "blacklist floppy" > /etc/modprobe.d/blacklist-floppy.conf4. dracut -f /boot/initramfs-$(uname -r).imgDebian/Ubuntu2. echo "blacklist floppy" > /etc/modprobe.d/blacklist-floppy.conf4. update-initramfs -uSLES (SuSE Linux Enterprise Server)2. echo "blacklist floppy" > /etc/modprobe.d/blacklist-floppy.conf4. mkinitrd
• 5. Reboot (optional)
• 3. cp /boot/initrd-$(uname -r) /boot/initrd-$(uname -r).backup
• 1. rmmod floppy
• 5. Reboot (optional)
• 3. cp /boot/initrd.img-$(uname -r) /boot/initrd.img-$(uname -r).backup
• 1. rmmod floppy
• 5. Reboot (optional)
• 3. cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.backup
• 1. rmmod floppy
• Do one of the following depending on your affected Operating System:

 

blk_update_request I/O error

간혹 VMware에 올린 RHEL 7 이 네트워크 이상으로 인해 reboot이 되면서 다음과 같은 error를 발생시키는 경우가 있다. (storage 연결이 잘못 끊어지는 경우 발생될 가능성이 높다.)

(실제 해당 log는 마지막에 출력된것으로 다른 에러들이 많다. 해당로그는 하나의 작은예..)

이후 재부팅시 emergency mode로 부팅이되고 fsck나 다른 command를 통한 해결이 안되는 문제가 발생된다.

 

실제 mount -a를 수행해보면 다음과 같은 에러가 발생된다.

 

[root@localhost ~]# mount -a

mount: special device /dev/mapper/rhel-home does not exist

 

[root@localhost ~]# lvscan

ACTIVE       '/dev/rhel/swap' [15.00 GiB] inherit

ACTIVE       '/dev/rhel/root' [50.00 GiB] inherit

inactive       '/dev/rhel/home' [35.00 GiB] inherit

 

이와 같은 경우 home directory volume에 문제가 있는 경우이다.

home directory를 fstab에서 변경해야 한다.

 

[root@localhost ~]# lvchange -a y /dev/rhel/home 

이와 같이 수행하면 inactive였던 lv가 active로 변경된다.

이후 mount -a를 수행해 /home을 mount 시킨후 파일을 백업한다.

 

간단하게는 아래와 같이 /usr/local/backup_files/로 복사하여 백업후 다시 restore 한다.

[root@localhost ~]# cp -rf /home/user /usr/local/backup_files/

 

마지막으로 fstab을 변경하여 emergency mode로 부팅이 되지 않도록 한다.

아래와 같이 home을 comment 한다.

[root@localhost ~]# vim /etc/fstab

#/dev/mapper/rhel-home   /home   xfs   defaults   0   0

 

이후 재부팅하면 emergency mode로 부팅되지 않고 정상부팅된다.

[root@localhost ~]# systemctl reboot

 

이후 기존 생성되어있는 계정에 맞는 home directory를 복사하여 기존 사용자정보를 그대로 사용한다.

 

blk_update_request: I/O error, dev fd0, sector 0

blk_update_request: I/O error, dev fd0, sector 0 가 계속 나오는 경우

ubuntu 기준작성

1. rmmod floppy
2. echo "blacklist floppy" > /etc/modprobe.d/blacklist-floppy.conf
3. cp /boot/initrd.img-치시고 tab누르시면 /boot/initrd.img-tab누르시고.back
4. update-initramfs -u
5. Reboot (optional)

 

[해결] blk_update_request i/o error dev fd0 sector 0 이슈 조치

입력/출력 오류 메시지와 함께 아무 데이터도 보이지 않음

[root@test-1 /home]# ls
ls: cannot open directory .: 입력/출력 오류

 

/var/log/messages 로그 확인

XFS파일 시스템 문제로 보임...

Jul 24 05:59:05 test-1 kernel: XFS (sda3): xfs_log_force: error -5 returned.
Jul 24 05:59:35 test-1 kernel: XFS (sda3): xfs_log_force: error -5 returned.

 

서버 재부팅 

XFS 파일시스템 sda3 파티션 메타데이터 관련 오류로 보이네요

 

Dmesg 에러 로그

blk_update_request i/o error dev fd0 sector 0

 

XFS 파일시스템 복구

먼저 read-only로 파일시스템 체크 후

xfs_repair -n /dev/sda3

 

파일시스템 복구

(마운트는 해제한 상태에서 진행할 것)

xfs_repair /dev/sda3