Qu'est-ce que les programmes voient quand ZFS ne peut pas fournir des données non corrompues?

Question

Dis mon programme tente une lecture d'un octet dans un fichier sur un système de fichiers ZFS. ZFS peut trouver une copie du bloc nécessaire, mais ne peut pas localiser une copie avec une somme de contrôle valide (ils sont tous corrompus, ou les seuls disques présents ont des copies corrompues). Qu'est-ce que mon programme voir, en termes de la valeur de retour de la lecture, et l'octet il a essayé de lire? Et est-il un moyen d'influencer le comportement (sous Solaris, ou tout autre ZFS mise en œuvre de système d'exploitation), qui est, la force échec, ou forcer le succès, avec des données potentiellement corrompues?

Answer 1

EIO est en effet la seule réponse avec les implémentations actuelles de ZFS.

Un ZFS ouvert « bug » demande une certaine façon de lire les données corrompues: http://bugs.opensolaris.org/bugdatabase/printableBug.do?bug_id=6186106

Je crois que ce qui est déjà faisable en utilisant le sans papier mais open source utilitaire ZDB. Jetez un oeil à http://www.cuddletech.com/blog/pivot /entry.php?id=980 pour obtenir des explications sur la façon de vider le contenu d'un fichier en utilisant l'option -R ZDB et le drapeau « r ».

Answer 2

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, [...]

Vous devez exporter / importer le pool de test parce que, sinon, l'écrasement direct (la corruption de la piscine) manquera car le fichier sera toujours mis en cache dans la mémoire OS.

Et non, actuellement ZFS refuse de vous donner des données corrompues. Comme il se doit.

Answer 3

Comment se retourner tout sauf une erreur de EIO de read() ont un sens en dehors d'un faible niveau spécifique système de fichiers utilitaire de récupération de données?

L'utilitaire de récupération de données à faible niveau aurait besoin d'utiliser une API spécifique OS et FS autre que d'ouverture / lecture / écriture / proche d'accéder au fichier. La sémantique dont il aurait besoin sont fondamentalement différents de la lecture des fichiers normaux, donc il aurait besoin d'une API spécialisée.