Pergunta

Digamos que meu programa de tentativas de leitura de um byte em um arquivo em um sistema de arquivos ZFS. ZFS pode localizar uma cópia do bloco necessário, mas não consegue localizar qualquer cópia com uma soma de verificação válido (eles estão todos corrompidos, ou os únicos discos presentes têm corrompido cópias). O que o meu programa de ver, em termos de valor de retorno a partir da leitura, eo byte que tentou ler? E se existe uma maneira de influenciar o comportamento (sob Solaris, ou quaisquer outros ZFS-implementação OS), isto é, a falha de força, ou sucesso vigor, com dados potencialmente corrupto?

Foi útil?

Solução

EIO é de fato a única resposta com ZFS atuais implementações.

Um ZFS aberto "bug" pede alguma maneira de ler os dados corrompidos: http://bugs.opensolaris.org/bugdatabase/printableBug.do?bug_id=6186106

Eu acredito que este é já factível usando o utilitário fonte zdb não documentado, mas aberto. Ter um olhar para http://www.cuddletech.com/blog/pivot /entry.php?id=980 para explicações sobre como despejar um conteúdo de arquivo usando a opção zdb -R e "r" bandeira.

Outras dicas

Solaris 10:

# Create a test pool
[root@tesalia z]# cd /tmp
[root@tesalia tmp]# mkfile 100M zz
[root@tesalia tmp]# zpool create prueba /tmp/zz

# Fill the pool
[root@tesalia /]# dd if=/dev/zero of=/prueba/dummy_file
dd: writing to `/prueba/dummy_file': No space left on device
129537+0 records in
129536+0 records out
66322432 bytes (66 MB) copied, 1.6093 s, 41.2 MB/s

# Umount the pool
[root@tesalia /]# zpool export prueba

# Corrupt the pool on purpose
[root@tesalia /]# dd if=/dev/urandom of=/tmp/zz seek=100000 count=1 conv=notrunc
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.0715209 s, 7.2 kB/s

# Mount the pool again
zpool import -d /tmp prueba

# Try to read the corrupted data
[root@tesalia tmp]# md5sum /prueba/dummy_file 
md5sum: /prueba/dummy_file: I/O error

# Read the manual
[root@tesalia tmp]# man -s2 read
[...]
RETURN VALUES
     Upon successful completion,  read()  and  readv()  return  a
     non-negative integer indicating the number of bytes actually
     read. Otherwise, the functions return -1 and  set  errno  to
     indicate the error.

ERRORS
     The read(), readv(), and pread() functions will fail if:
[...]
     EIO        A physical I/O error has occurred, [...]

Você deve exportar / importar o pool de teste porque, se não, a escrita directa (piscina corrupção) será perdido desde que o arquivo ainda será armazenada na memória OS.

E não, atualmente o ZFS vai recusar-se a dar-lhe dados corrompidos. Como deveria.

Como iria retornar nada, mas um erro EIO de read() faz sentido fora de uma utilidade específica sistema de arquivo baixo nível de resgate de dados?

O utilitário de resgate de dados de baixo nível seria necessário usar um sistema operacional e FS específica API diferente / open read / write / close para acessar o arquivo. A semântica de que necessitaria são fundamentalmente diferentes de leitura de arquivos normais, por isso seria necessário um API especializada.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top