dmesg에서 USB 드라이브가 오프라인인가요? ls에 있지만 특정 파일에만 해당됩니까?

dmesg에서 USB 드라이브가 오프라인인가요? ls에 있지만 특정 파일에만 해당됩니까?

백업 드라이브가 있는데 최근에 rsnapshot을 실행할 때 간헐적으로 실패했습니다(그러나 거의 항상 성공했습니다).

lse2label결과는 고무적이지 않습니다 .

$ ls -al /mnt/backup/
ls: cannot access /mnt/backup/daily.3: Input/output error
ls: cannot access /mnt/backup/daily.5: Input/output error
ls: cannot access /mnt/backup/weekly.3: Input/output error
ls: cannot access /mnt/backup/monthly.1: Input/output error
ls: cannot access /mnt/backup/weekly.1: Input/output error
ls: cannot access /mnt/backup/daily.1: Input/output error
ls: cannot access /mnt/backup/daily.0: Input/output error
ls: cannot access /mnt/backup/weekly.2: Input/output error
ls: cannot access /mnt/backup/daily.4: Input/output error
total 52
drwxr-xr-x 19 root root  4096 Aug 12 20:01 .
drwxr-xr-x  7 root root  4096 Jun 18 19:08 ..
d?????????  ? ?    ?        ?            ? daily.0
d?????????  ? ?    ?        ?            ? daily.1
d?????????  ? ?    ?        ?            ? daily.3
d?????????  ? ?    ?        ?            ? daily.4
d?????????  ? ?    ?        ?            ? daily.5
dr-xr-xr-x 19 root root  4096 Aug 13 06:00 daily.6
drwx------  2 root root 16384 Mar 26 13:13 lost+found
dr-xr-xr-x 23 root root  4096 Aug 12 20:01 minutes.0
dr-xr-xr-x 23 root root  4096 Aug 10 19:54 minutes.2
dr-xr-xr-x 23 root root  4096 Aug  8 22:24 minutes.3
dr-xr-xr-x 23 root root  4096 Aug  8 17:26 minutes.4
dr-xr-xr-x 23 root root  4096 May 18 19:39 monthly.0
d?????????  ? ?    ?        ?            ? monthly.1
dr-xr-xr-x 23 root root  4096 Jul 13 20:04 weekly.0
d?????????  ? ?    ?        ?            ? weekly.1
d?????????  ? ?    ?        ?            ? weekly.2
d?????????  ? ?    ?        ?            ? weekly.3

$ e2label /mnt/backup
e2label: Attempt to read block from filesystem resulted in short read while trying to open /mnt/backup
Couldn't find valid filesystem superblock.

그러나 이상하게도 dmesg드라이브가 오프라인 상태라고 보고됩니다.

$ dmesg | tail
sd 2:0:0:0: rejecting I/O to offline device
sd 2:0:0:0: rejecting I/O to offline device
sd 2:0:0:0: rejecting I/O to offline device
EXT4-fs error (device sdc1): __ext4_get_inode_loc: unable to read inode block - inode=50729874, block=202899801
sd 2:0:0:0: rejecting I/O to offline device
sd 2:0:0:0: rejecting I/O to offline device
EXT4-fs error (device sdc1): __ext4_get_inode_loc: unable to read inode block - inode=50331649, block=201326624
sd 2:0:0:0: rejecting I/O to offline device
sd 2:0:0:0: rejecting I/O to offline device
EXT4-fs error (device sdc1): __ext4_get_inode_loc: unable to read inode block - inode=47185921, block=188743712

때때로 우리는 또한 다음을 얻습니다:

EXT4-fs error (device sdc1): ext4_put_super: Couldn't clean up the journal

최근 HyperV 패스스루로 가상 머신에 대한 장치의 연결을 끊었다가 다시 연결할 때 많은 dmesg 메시지를 받았습니다.

scsi scan: INQUIRY result too short (5), using 36

...지금은 전혀 설치할 수 없습니다.

이제 오프라인인 경우 출력을 어떻게 볼 수 있습니까 ls?

이는 백업이 수행된 호스트 가상 머신의 손상, USB 하드 드라이브의 하드웨어 문제 또는 둘 다를 나타낼 가능성이 더 높습니까?

고쳐 쓰다:포맷할 수도 없습니다.

$ sudo mkfs.ext4 -L 2015backup2new /dev/sdc1
mke2fs 1.41.12 (17-May-2010)
mkfs.ext4: No such device or address while trying to determine filesystem size

해당 파티션을 보거나 수정할 수 없습니다.

$ sudo fdisk -l /dev/sdc
$ sudo fdisk /dev/sdc

Unable to open /dev/sdc

그러나 그것은 존재합니다:

$ sudo ls -al /dev/sdc*
brw-rw---- 1 root disk 8, 32 Aug 10 15:26 /dev/sdc
brw-rw---- 1 root disk 8, 33 Aug 10 15:26 /dev/sdc1

파티션도 무시할 수 없습니다.

$ sudo mkfs.ext4 -L 2015backup2new /dev/sdc
mke2fs 1.41.12 (17-May-2010)
/dev/sdc is entire device, not just one partition!
Proceed anyway? (y,n) y
mkfs.ext4: No such device or address while trying to determine filesystem size

고쳐 쓰다:흥미롭게도 이제 다른 두 개의 USB 드라이브에서도 이 문제가 발생하고 있습니다. 하지만 그 중 하나를 CentOS7 이미지(우리가 사용하고 있는 기본 6.5 이미지 대신)에 연결하면 형식이 제대로 지정되고 설치됩니다. (CentOS 7의 dmesg 출력도 scsi 3:0:0:1: scsi scan: INQUIRY result too short (5), using 36몇 번 표시되었지만 여전히 작동했습니다.) 그러나 포맷된 드라이브를 분리한 다음 CentOS 6.5 이미지에 다시 연결하면 여전히 위의 모든 오류가 발생했습니다(처음에 표시된 부분 오류 제외). ㅋㅋㅋ).

답변1

실제 하드웨어 문제를 해결할 수는 없지만 진단상의 혼란을 해결할 수는 있습니다.

사용 가능한 파티션에 대한 실제 공식 소스는 입니다 /proc/partitions. /dev에 장치 노드가 있다고 해서 아무 의미가 없습니다. 실제로 아주 오래된 Linux 배포판에서는 시스템에서 사용 가능한 항목에 관계없이 가능한 모든 장치 이름으로 /dev를 채웠습니다. 사용자의 편의를 위해 필요에 따라 장치 노드를 생성하는 새로운 방법이 있습니다.

디렉터리의 경우 결과는 파일 시스템 캐싱으로 인해 발생합니다. 디렉토리에는 파일 이름 목록과 "inodes"(파일 ID 번호)만 포함됩니다. 소유권, 권한, 타임스탬프 등 파일에 대한 나머지 세부정보는 파일 자체에서 가져옵니다. 디렉터리를 나열하면 먼저 파일 목록을 쿼리한 다음 각 파일에 대해 "stat"를 실행하여 나머지 데이터를 로드합니다. 디렉터리가 캐시되고 일부 파일이 캐시되었지만 아직 캐시되지 않은 파일을 계산할 수 없는 경우 위에 붙여넣은 것과 유사한 출력이 표시됩니다.

dmesg는 "더 이상 장치에 액세스할 수 없습니다"라고 올바르게 설명합니다.

관련 정보