J'ai, sur une clé USB, une partition FAT suivie d'une ext4.
Je peux parfaitement lire le contenu de la partition ext4 sous Windows
avec ext2explore (programme qui sait lire mais pas écrire), j'en déduis
que la partition n'est pas totalement perdue.
Sous Linux, immontable :
-----------------------------------------------------------------------
> mount /dev/disk/by-label/Linux_partition
mount : type erroné de syst .de fichiers, option erronée, super bloc
erroné sur /dev/sdc2, codepage ou aide manquante ou autre erreur
Dans quelques cas certaines informations sont utiles dans syslog - essayez
dmesg | tail ou quelque chose du genre
> dmesg|tail
[276084.705188] sd 12:0:0:0: [sdc] Add. Sense: Write protected
[276084.705191] end_request: I/O error, dev sdc, sector 10448328
[276084.706039] sd 12:0:0:0: [sdc] Unhandled sense code
[276084.706046] sd 12:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[276084.706053] sd 12:0:0:0: [sdc] Sense Key : Data Protect [current]
[276084.706064] Info fld=0x0
[276084.706065] sd 12:0:0:0: [sdc] Add. Sense: Write protected
[276084.706069] end_request: I/O error, dev sdc, sector 10448344
[276084.707103] JBD: recovery failed
[276084.707109] EXT4-fs (sdc2): error loading journal
-----------------------------------------------------------------------
dumpe2fs ne râle pas. J'ai essayé diverses réparation avec e2fsck, aussi
en utilisant des superblocs de secours, mais le montage est toujours
impossible. Quelque chose cloche, car si je fais :
-----------------------------------------------------------------------
> e2fsck /dev/disk/by-label/Linux_partition
e2fsck 1.41.9 (22-Aug-2009)
Linux_partition : récupération du journal
le drapeau needs_recovery n'est pas activé, mais le journal contient des données.
Exécuter quand même le journal<o>? non
Effacer le journal<o>? oui
Le drapeau test_fs est positionné (et ext4 est disponible). Effacer<o>? oui
Linux_partition n'a pas été démonté proprement, vérification forcée.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Numéro d'i-noeud invalide pour « . » dans l'i-noeud de répertoire 72.
Corriger<o>? oui
l'entrée « figures » dans [...] (72) est un lien vers « . » Effacer<o>? oui
(diverses erreurs, je réponds toujours oui, dans les passes 3 et 4 aussi)
Passe 5 : vérification de l'information du sommaire de groupe
Linux_partition: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
Linux_partition : 3600/428240 fichiers (0.1% non contigus), 340958/1710688 blocs
-----------------------------------------------------------------------
et que je recommence, il me dit encore
-----------------------------------------------------------------------
Linux_partition : récupération du journal
le drapeau needs_recovery n'est pas activé, mais le journal contient des données.
Exécuter quand même le journal<o>?
-----------------------------------------------------------------------
donc l'effacement du journal n'a pas été fait. Je pense à un bloc foireux,
mais si j'utilise un superbloc de secours j'ai le même problème. Avec
e2fsck -c il ne trouve pas de badblock, avec -cc j'obtiens des milliers de
lignes du type :
-----------------------------------------------------------------------
badblocks: Erreur d'entrée/sortie lors du test d'écriture de données, bloc 1709568
-----------------------------------------------------------------------
puis :
-----------------------------------------------------------------------
complété
Linux_partition: Updating bad block inode.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
l'i-noeud racine n'est pas un répertoire ; arrêt immédiat.
e2fsck: arrêté
-----------------------------------------------------------------------
Ensuite, dumpe2fs -b ne renvoie toujours rien !
Que puis-je essayer d'autre ? (A priori je n'ai rien d'essentiel sur cette
partition, qui me sert pour le backup et le transfert entre machines.)
J'ai fait des essais avec 4 superblocs de secours, il en reste 4 que je
n'ai pas touchés.
Est-ce que e2fsck peut travailler sur une copie de la partition dans un
fichier (faite avec dd) ?
Oui, la lecture se fait sans problème donc j'ai pu faire une copie.
Ce qui tendrait à démontrer que la clef n'est pas morte
Mais une clef sur laquelle on ne peut plus écrire n'est pas franchement utile !
Quant à savoir si la copie est fidèle...
Qu'est ce qui pourrait justifier qu'elle ne le soit pas ? Ce qui ne veut évidemment pas dire que les données ne soient pas corrompues (ce qui ne me semble pas être la même chose).
Ah, je ne fais pas la différence. Disons que je ne suis pas sûr que les données récupérées sont identiques à celles que j'avais mises !
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
Le 7 octobre 2013, Dominique MICOLLET a écrit :
Lucas Levrel wrote:
Oui, la lecture se fait sans problème donc j'ai pu faire une copie.
Ce qui tendrait à démontrer que la clef n'est pas morte
Mais une clef sur laquelle on ne peut plus écrire n'est pas franchement
utile !
Quant à savoir si la copie est fidèle...
Qu'est ce qui pourrait justifier qu'elle ne le soit pas ?
Ce qui ne veut évidemment pas dire que les données ne soient pas corrompues
(ce qui ne me semble pas être la même chose).
Ah, je ne fais pas la différence. Disons que je ne suis pas sûr que les
données récupérées sont identiques à celles que j'avais mises !
Oui, la lecture se fait sans problème donc j'ai pu faire une copie.
Ce qui tendrait à démontrer que la clef n'est pas morte
Mais une clef sur laquelle on ne peut plus écrire n'est pas franchement utile !
Quant à savoir si la copie est fidèle...
Qu'est ce qui pourrait justifier qu'elle ne le soit pas ? Ce qui ne veut évidemment pas dire que les données ne soient pas corrompues (ce qui ne me semble pas être la même chose).
Ah, je ne fais pas la différence. Disons que je ne suis pas sûr que les données récupérées sont identiques à celles que j'avais mises !
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
Dominique MICOLLET
Bonjour,
Lucas Levrel wrote:
Mais une clef sur laquelle on ne peut plus écrire n'est pas franchement utile !
Certes. Mais si la lecture est possible, il est au moins possible de récupérer les données.
Ah, je ne fais pas la différence. Disons que je ne suis pas sûr que les données récupérées sont identiques à celles que j'avais mises !
La corruption des données peut s'être produite à l'écriture. De ce fait les données sont corrompues sur le support et relues comme telles, fidèlement.
Ce genre de choses semble se produire lorsqu'on retire précipitament un support amovible alors que le système d'exploitation est encore en train d'écrire dessus, ou qu'il n'a pas vidé ses tampons.
Certes, à terme, cela revient au même. Sauf que la clef fonctionne peut-être correctement.
Cordialement
Dominique.
Bonjour,
Lucas Levrel wrote:
Mais une clef sur laquelle on ne peut plus écrire n'est pas franchement
utile !
Certes.
Mais si la lecture est possible, il est au moins possible de récupérer les
données.
Ah, je ne fais pas la différence. Disons que je ne suis pas sûr que les
données récupérées sont identiques à celles que j'avais mises !
La corruption des données peut s'être produite à l'écriture. De ce fait les
données sont corrompues sur le support et relues comme telles, fidèlement.
Ce genre de choses semble se produire lorsqu'on retire précipitament un
support amovible alors que le système d'exploitation est encore en train
d'écrire dessus, ou qu'il n'a pas vidé ses tampons.
Certes, à terme, cela revient au même. Sauf que la clef fonctionne peut-être
correctement.
Mais une clef sur laquelle on ne peut plus écrire n'est pas franchement utile !
Certes. Mais si la lecture est possible, il est au moins possible de récupérer les données.
Ah, je ne fais pas la différence. Disons que je ne suis pas sûr que les données récupérées sont identiques à celles que j'avais mises !
La corruption des données peut s'être produite à l'écriture. De ce fait les données sont corrompues sur le support et relues comme telles, fidèlement.
Ce genre de choses semble se produire lorsqu'on retire précipitament un support amovible alors que le système d'exploitation est encore en train d'écrire dessus, ou qu'il n'a pas vidé ses tampons.
Certes, à terme, cela revient au même. Sauf que la clef fonctionne peut-être correctement.
Cordialement
Dominique.
La Bete des Vosges (Francis Chartier)
Le Mon, 07 Oct 2013 06:00:55 +0000, JKB a écrit :
Mon expérience me dit qu'à moins d'une grosse évolution
technologique,
le bon vieux disque dur en raid est bien meilleur qu'un SSD de compétition. Je ne parle pas des temps d'accès, mais de la
fiabilité de
la chose.
La technologie est plus mature et à la condition de ne pas choisir dans le matériel cheap on doit avoir quelque chose de plus fiable, particulièrement dans les disques pour serveurs SCSI ou SAS.
Je suis toujours surpris de trouver chez des clients de vieilles machines datant de la première moitié des années 90, sous NT3,5 ou Novell, et qui tournent 24x7 avec leurs disques SCSI d'origine brassés quotidiennement. Bon, on n'ose plus les éteindre. :)
-- La Bête des Vosges - Francis Chartier
Le Mon, 07 Oct 2013 06:00:55 +0000, JKB a écrit :
Mon expérience me dit qu'à moins d'une grosse évolution
technologique,
le bon vieux disque dur en raid est bien meilleur qu'un SSD de
compétition. Je ne parle pas des temps d'accès, mais de la
fiabilité de
la chose.
La technologie est plus mature et à la condition de ne pas choisir dans
le matériel cheap on doit avoir quelque chose de plus fiable,
particulièrement dans les disques pour serveurs SCSI ou SAS.
Je suis toujours surpris de trouver chez des clients de vieilles machines
datant de la première moitié des années 90, sous NT3,5 ou Novell, et qui
tournent 24x7 avec leurs disques SCSI d'origine brassés quotidiennement.
Bon, on n'ose plus les éteindre. :)
Mon expérience me dit qu'à moins d'une grosse évolution
technologique,
le bon vieux disque dur en raid est bien meilleur qu'un SSD de compétition. Je ne parle pas des temps d'accès, mais de la
fiabilité de
la chose.
La technologie est plus mature et à la condition de ne pas choisir dans le matériel cheap on doit avoir quelque chose de plus fiable, particulièrement dans les disques pour serveurs SCSI ou SAS.
Je suis toujours surpris de trouver chez des clients de vieilles machines datant de la première moitié des années 90, sous NT3,5 ou Novell, et qui tournent 24x7 avec leurs disques SCSI d'origine brassés quotidiennement. Bon, on n'ose plus les éteindre. :)
-- La Bête des Vosges - Francis Chartier
Emmanuel Florac
Le Mon, 07 Oct 2013 06:00:55 +0000, JKB a écrit:
Mon expérience me dit qu'à moins d'une grosse évolution technologique, le bon vieux disque dur en raid est bien meilleur qu'un SSD de compétition.
Bof, ça dépend. Ma machine de compil tourne avec des SSD de 2008, et malgré une utilisation assez intense aucun de ces SSD de 16 Go n'a cramé. Oui, des SSD de 16 Go qui coûtaient à l'époque plus de 500 euros pièce: M- TRON c'était pas de la camelote.
-- Don't worry about people stealing your ideas. If it's original, you'll have to ram it down their throats. Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
Le Mon, 07 Oct 2013 06:00:55 +0000, JKB a écrit:
Mon expérience me dit qu'à moins d'une grosse évolution technologique,
le bon vieux disque dur en raid est bien meilleur qu'un SSD de
compétition.
Bof, ça dépend. Ma machine de compil tourne avec des SSD de 2008, et
malgré une utilisation assez intense aucun de ces SSD de 16 Go n'a cramé.
Oui, des SSD de 16 Go qui coûtaient à l'époque plus de 500 euros pièce: M-
TRON c'était pas de la camelote.
--
Don't worry about people stealing your ideas. If it's original, you'll
have to ram it down their throats.
Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
Mon expérience me dit qu'à moins d'une grosse évolution technologique, le bon vieux disque dur en raid est bien meilleur qu'un SSD de compétition.
Bof, ça dépend. Ma machine de compil tourne avec des SSD de 2008, et malgré une utilisation assez intense aucun de ces SSD de 16 Go n'a cramé. Oui, des SSD de 16 Go qui coûtaient à l'époque plus de 500 euros pièce: M- TRON c'était pas de la camelote.
-- Don't worry about people stealing your ideas. If it's original, you'll have to ram it down their throats. Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
JKB
Le 07 Oct 2013 19:25:22 GMT, Emmanuel Florac écrivait :
Le Mon, 07 Oct 2013 06:00:55 +0000, JKB a écrit:
Mon expérience me dit qu'à moins d'une grosse évolution technologique, le bon vieux disque dur en raid est bien meilleur qu'un SSD de compétition.
Bof, ça dépend. Ma machine de compil tourne avec des SSD de 2008, et malgré une utilisation assez intense aucun de ces SSD de 16 Go n'a cramé. Oui, des SSD de 16 Go qui coûtaient à l'époque plus de 500 euros pièce: M- TRON c'était pas de la camelote.
Entre nous, ceux que j'ai sous la main ne sont pas exactement de la camelote non plus... Aujourd'hui, je n'en ai pas un qui a dépassé un an de bons et loyaux services. Les derniers étaient des Kingston business ou quelque chose du genre de 64 Go. Ça chauffe et ça n'aime pas le chaud.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 07 Oct 2013 19:25:22 GMT,
Emmanuel Florac <eflorac@imaginet.fr> écrivait :
Le Mon, 07 Oct 2013 06:00:55 +0000, JKB a écrit:
Mon expérience me dit qu'à moins d'une grosse évolution technologique,
le bon vieux disque dur en raid est bien meilleur qu'un SSD de
compétition.
Bof, ça dépend. Ma machine de compil tourne avec des SSD de 2008, et
malgré une utilisation assez intense aucun de ces SSD de 16 Go n'a cramé.
Oui, des SSD de 16 Go qui coûtaient à l'époque plus de 500 euros pièce: M-
TRON c'était pas de la camelote.
Entre nous, ceux que j'ai sous la main ne sont pas exactement de la
camelote non plus... Aujourd'hui, je n'en ai pas un qui a dépassé un
an de bons et loyaux services. Les derniers étaient des Kingston
business ou quelque chose du genre de 64 Go. Ça chauffe et ça n'aime
pas le chaud.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 07 Oct 2013 19:25:22 GMT, Emmanuel Florac écrivait :
Le Mon, 07 Oct 2013 06:00:55 +0000, JKB a écrit:
Mon expérience me dit qu'à moins d'une grosse évolution technologique, le bon vieux disque dur en raid est bien meilleur qu'un SSD de compétition.
Bof, ça dépend. Ma machine de compil tourne avec des SSD de 2008, et malgré une utilisation assez intense aucun de ces SSD de 16 Go n'a cramé. Oui, des SSD de 16 Go qui coûtaient à l'époque plus de 500 euros pièce: M- TRON c'était pas de la camelote.
Entre nous, ceux que j'ai sous la main ne sont pas exactement de la camelote non plus... Aujourd'hui, je n'en ai pas un qui a dépassé un an de bons et loyaux services. Les derniers étaient des Kingston business ou quelque chose du genre de 64 Go. Ça chauffe et ça n'aime pas le chaud.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
