drive USB off-line no dmesg e? em ls, mas apenas para alguns arquivos?

Question

Eu tenho uma unidade de backup que tem falhado intermitentemente (mas quase sempre bem-sucedida) para executar o rsnapshot recentemente.

ls e e2label output não são animadores:

$ 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.

Mas o que é estranho é que dmesg informa que a unidade está off-line:

$ 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

Às vezes também recebemos:

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

E, ultimamente, desatualizando e reconectando o dispositivo como passagem de HyperV para a VM, conseguimos que muitos deles sejam dmesg:

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

... e agora não pode montá-lo.

Agora, se estiver off-line, como posso ver qualquer saída de ls ?

É mais provável que isso indique a corrupção da VM hospedeira que está fazendo o backup ou que o disco rígido USB tenha problemas de hardware ou ambos?

UPDATE: eu também não posso formatá-lo:

$ 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

E não consigo ver nem modificar suas partições:

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

Unable to open /dev/sdc

Mas existe:

$ 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

Eu também não posso ignorar a partição:

$ 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

UPDATE: Curiosamente, duas outras unidades USB agora apresentam esse problema. Mas se eu anexar algum deles a uma imagem do CentOS7 (em vez da imagem principal do 6.5 com a qual estávamos trabalhando), ela será formatada e montada OK. (A saída dmesg do CentOS 7 também mostra scsi 3:0:0:1: scsi scan: INQUIRY result too short (5), using 36 várias vezes, mas funciona assim mesmo.) No entanto, desanexar e anexar a unidade formatada de volta à imagem do CentOS 6.5 ainda exibe todos os erros acima (exceto a exibição parcial inicial de ls. )

    

Answer 1

Eu não tenho uma resposta para o seu problema real de hardware, mas posso esclarecer a confusão sobre o seu diagnóstico.

A fonte oficial real para quais partições estão disponíveis é /proc/partitions . Só porque existe um nó de dispositivo no / dev realmente não significa nada. Na verdade, em distribuições de linux realmente antigas eles deviam preencher / dev com todos os nomes de dispositivos possíveis, independentemente de quais estivessem disponíveis no sistema. Os métodos mais recentes de criar nós de dispositivo sob demanda são para sua conveniência.

Quanto aos diretórios, seus resultados são causados pelo cache do sistema de arquivos. Um diretório contém apenas uma lista de nomes de arquivos e "inodes" (números de identificação de arquivo). O restante dos detalhes sobre um arquivo como propriedade, permissões e carimbos de data e hora vem do próprio arquivo. Quando você lista um diretório, ele começa consultando a lista de arquivos e, em seguida, executa "stat" em cada arquivo para carregar o restante dos dados. Se o diretório for armazenado em cache e alguns dos arquivos forem armazenados em cache, mas não for possível determinar nenhum arquivo que ainda não tenha sido armazenado em cache, você verá a saída como a que você colou acima.

O dmesg está corretamente explicando que "não podemos mais alcançar este dispositivo".