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) ?
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
-- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. C.A.R. Hoare.
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear
leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
--
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
C.A.R. Hoare.
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
-- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. C.A.R. Hoare.
Geo Cherchetout
Le 04/10/2013 22:04, *125* a écrit fort à propos :
Un petit coup de testdisk des fois.
Voire un petit coup de ddrescue.
Le 04/10/2013 22:04, *125* a écrit fort à propos :
Le 04/10/2013 22:04, *125* a écrit fort à propos :
Un petit coup de testdisk des fois.
Voire un petit coup de ddrescue.
Lucas Levrel
Le 4 octobre 2013, Dominique MICOLLET a écrit :
A tenter peut-être : un dd de la clef complète sur un fichier et un montage des partitions de ce dernier par un loopback (il me semble que c'est possible). Si le dd passe c'est que la clef n'est pas totalement morte. Ensuite on peut faire ce qu'on veut avec le fichier.
Oui, la lecture se fait sans problème donc j'ai pu faire une copie. Quant à savoir si la copie est fidèle... J'ai pu monter la copie de la partition FAT, je n'ai pas encore essayé la copie de celle en ext4.
Et quelques fois on récupère physiquement une clef en la remplissant à ras bord de zéro.
L'utilitaire constructeur semble avoir fait son office. La table de partitions semble indiquer qu'il y a 2048 secteurs de moins qu'avant (mais comme, étrangement, la pseudo géométrie C/H/S a changé, c'est peut-être une sorte d'erreur d'arrondi).
-- LL
Le 4 octobre 2013, Dominique MICOLLET a écrit :
A tenter peut-être : un dd de la clef complète sur un fichier et un montage
des partitions de ce dernier par un loopback (il me semble que c'est
possible).
Si le dd passe c'est que la clef n'est pas totalement morte.
Ensuite on peut faire ce qu'on veut avec le fichier.
Oui, la lecture se fait sans problème donc j'ai pu faire une copie. Quant
à savoir si la copie est fidèle... J'ai pu monter la copie de la partition
FAT, je n'ai pas encore essayé la copie de celle en ext4.
Et quelques fois on récupère physiquement une clef en la remplissant à ras
bord de zéro.
L'utilitaire constructeur semble avoir fait son office. La table de
partitions semble indiquer qu'il y a 2048 secteurs de moins qu'avant (mais
comme, étrangement, la pseudo géométrie C/H/S a changé, c'est peut-être
une sorte d'erreur d'arrondi).
A tenter peut-être : un dd de la clef complète sur un fichier et un montage des partitions de ce dernier par un loopback (il me semble que c'est possible). Si le dd passe c'est que la clef n'est pas totalement morte. Ensuite on peut faire ce qu'on veut avec le fichier.
Oui, la lecture se fait sans problème donc j'ai pu faire une copie. Quant à savoir si la copie est fidèle... J'ai pu monter la copie de la partition FAT, je n'ai pas encore essayé la copie de celle en ext4.
Et quelques fois on récupère physiquement une clef en la remplissant à ras bord de zéro.
L'utilitaire constructeur semble avoir fait son office. La table de partitions semble indiquer qu'il y a 2048 secteurs de moins qu'avant (mais comme, étrangement, la pseudo géométrie C/H/S a changé, c'est peut-être une sorte d'erreur d'arrondi).
-- LL
Lucas Levrel
Le 4 octobre 2013, Emmanuel Florac a écrit :
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
C'est effectivement bon à savoir ! J'étais resté à la même croyance que Dominique.
Ceci dit, ma clef n'est pas tout-à-fait une noname (Transcend). Il y a peut-être des marques de clef intégrant un « wear leveller » ?
-- LL
Le 4 octobre 2013, Emmanuel Florac a écrit :
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear
leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
C'est effectivement bon à savoir ! J'étais resté à la même croyance que
Dominique.
Ceci dit, ma clef n'est pas tout-à-fait une noname (Transcend). Il y a
peut-être des marques de clef intégrant un « wear leveller » ?
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
C'est effectivement bon à savoir ! J'étais resté à la même croyance que Dominique.
Ceci dit, ma clef n'est pas tout-à-fait une noname (Transcend). Il y a peut-être des marques de clef intégrant un « wear leveller » ?
-- LL
JKB
Le Sat, 5 Oct 2013 12:47:18 +0200, Lucas Levrel écrivait :
Le 4 octobre 2013, Emmanuel Florac a écrit :
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
C'est effectivement bon à savoir ! J'étais resté à la même croyance que Dominique.
Ceci dit, ma clef n'est pas tout-à-fait une noname (Transcend). Il y a peut-être des marques de clef intégrant un « wear leveller » ?
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en utilise pour des trucs en électronique embarquée chez un client, et vu la fiabilité des choses, ce n'est pas demain que je vais mettre des données sensibles dessus (et ce sont des SSD onéreux, pas la gamme grand public).
J'obtiens de meilleurs résultats avec un adaptateur SATS-CF et des cartes CF SLC montée en ubifs sur mtdblock.
Enfin, je dis ça je dis rien...
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 Sat, 5 Oct 2013 12:47:18 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
Le 4 octobre 2013, Emmanuel Florac a écrit :
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear
leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
C'est effectivement bon à savoir ! J'étais resté à la même croyance que
Dominique.
Ceci dit, ma clef n'est pas tout-à-fait une noname (Transcend). Il y a
peut-être des marques de clef intégrant un « wear leveller » ?
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en
utilise pour des trucs en électronique embarquée chez un client, et
vu la fiabilité des choses, ce n'est pas demain que je vais mettre
des données sensibles dessus (et ce sont des SSD onéreux, pas la
gamme grand public).
J'obtiens de meilleurs résultats avec un adaptateur SATS-CF et des
cartes CF SLC montée en ubifs sur mtdblock.
Enfin, je dis ça je dis rien...
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 Sat, 5 Oct 2013 12:47:18 +0200, Lucas Levrel écrivait :
Le 4 octobre 2013, Emmanuel Florac a écrit :
Le Fri, 04 Oct 2013 17:45:07 +0200, Dominique MICOLLET a écrit:
Je croyais que les controlleurs des clefs USB intégraient un "wear leveller".
Les contrôleurs de SSD, oui. De clef USB à 4 euros, définitivement non.
C'est effectivement bon à savoir ! J'étais resté à la même croyance que Dominique.
Ceci dit, ma clef n'est pas tout-à-fait une noname (Transcend). Il y a peut-être des marques de clef intégrant un « wear leveller » ?
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en utilise pour des trucs en électronique embarquée chez un client, et vu la fiabilité des choses, ce n'est pas demain que je vais mettre des données sensibles dessus (et ce sont des SSD onéreux, pas la gamme grand public).
J'obtiens de meilleurs résultats avec un adaptateur SATS-CF et des cartes CF SLC montée en ubifs sur mtdblock.
Enfin, je dis ça je dis rien...
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
La Bete des Vosges (Francis Chartier)
Le Sat, 05 Oct 2013 13:14:44 +0000, JKB a écrit :
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en utilise pour des trucs en électronique embarquée chez un client,
et vu
la fiabilité des choses, ce n'est pas demain que je vais mettre
des
données sensibles dessus (et ce sont des SSD onéreux, pas la gamme grand public).
Dans ce genre d'usage (remplacement du disque pour un ancien serveur utilisant un OS ne gérant pas les particularités des SSD), j'avais opté pour un SSD PATA de chez Transcend, qui est censé gérer ce genre de contraintes, justement. Maintenant, pas de stats sur des volumes suffisamment importants pour savoir si c'est réellement plus fiable ou si ça relève du simple discours commercial sans réel fondement.
Il existe sûrement des solutions plus solides, mais encore faut-il que ça soit justifiable économiquement, selon les situations.
-- La Bête des Vosges - Francis Chartier
Le Sat, 05 Oct 2013 13:14:44 +0000, JKB a écrit :
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en
utilise pour des trucs en électronique embarquée chez un client,
et vu
la fiabilité des choses, ce n'est pas demain que je vais mettre
des
données sensibles dessus (et ce sont des SSD onéreux, pas la gamme
grand public).
Dans ce genre d'usage (remplacement du disque pour un ancien serveur
utilisant un OS ne gérant pas les particularités des SSD), j'avais opté
pour un SSD PATA de chez Transcend, qui est censé gérer ce genre de
contraintes, justement.
Maintenant, pas de stats sur des volumes suffisamment importants pour
savoir si c'est réellement plus fiable ou si ça relève du simple discours
commercial sans réel fondement.
Il existe sûrement des solutions plus solides, mais encore faut-il que ça
soit justifiable économiquement, selon les situations.
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en utilise pour des trucs en électronique embarquée chez un client,
et vu
la fiabilité des choses, ce n'est pas demain que je vais mettre
des
données sensibles dessus (et ce sont des SSD onéreux, pas la gamme grand public).
Dans ce genre d'usage (remplacement du disque pour un ancien serveur utilisant un OS ne gérant pas les particularités des SSD), j'avais opté pour un SSD PATA de chez Transcend, qui est censé gérer ce genre de contraintes, justement. Maintenant, pas de stats sur des volumes suffisamment importants pour savoir si c'est réellement plus fiable ou si ça relève du simple discours commercial sans réel fondement.
Il existe sûrement des solutions plus solides, mais encore faut-il que ça soit justifiable économiquement, selon les situations.
-- La Bête des Vosges - Francis Chartier
JKB
Le Mon, 7 Oct 2013 05:41:11 +0000 (UTC), La Bete des Vosges (Francis Chartier) écrivait :
Le Sat, 05 Oct 2013 13:14:44 +0000, JKB a écrit :
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en utilise pour des trucs en électronique embarquée chez un client,
et vu
la fiabilité des choses, ce n'est pas demain que je vais mettre
des
données sensibles dessus (et ce sont des SSD onéreux, pas la gamme grand public).
Dans ce genre d'usage (remplacement du disque pour un ancien serveur utilisant un OS ne gérant pas les particularités des SSD), j'avais opté pour un SSD PATA de chez Transcend, qui est censé gérer ce genre de contraintes, justement. Maintenant, pas de stats sur des volumes suffisamment importants pour savoir si c'est réellement plus fiable ou si ça relève du simple discours commercial sans réel fondement.
Il existe sûrement des solutions plus solides, mais encore faut-il que ça soit justifiable économiquement, selon les situations.
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.
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 Mon, 7 Oct 2013 05:41:11 +0000 (UTC),
La Bete des Vosges (Francis Chartier) <francis@bete-des-vosges.org> écrivait :
Le Sat, 05 Oct 2013 13:14:44 +0000, JKB a écrit :
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en
utilise pour des trucs en électronique embarquée chez un client,
et vu
la fiabilité des choses, ce n'est pas demain que je vais mettre
des
données sensibles dessus (et ce sont des SSD onéreux, pas la gamme
grand public).
Dans ce genre d'usage (remplacement du disque pour un ancien serveur
utilisant un OS ne gérant pas les particularités des SSD), j'avais opté
pour un SSD PATA de chez Transcend, qui est censé gérer ce genre de
contraintes, justement.
Maintenant, pas de stats sur des volumes suffisamment importants pour
savoir si c'est réellement plus fiable ou si ça relève du simple discours
commercial sans réel fondement.
Il existe sûrement des solutions plus solides, mais encore faut-il que ça
soit justifiable économiquement, selon les situations.
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.
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 Mon, 7 Oct 2013 05:41:11 +0000 (UTC), La Bete des Vosges (Francis Chartier) écrivait :
Le Sat, 05 Oct 2013 13:14:44 +0000, JKB a écrit :
Et même sur les SSD, ça ne fonctionne pas terriblement bien. J'en utilise pour des trucs en électronique embarquée chez un client,
et vu
la fiabilité des choses, ce n'est pas demain que je vais mettre
des
données sensibles dessus (et ce sont des SSD onéreux, pas la gamme grand public).
Dans ce genre d'usage (remplacement du disque pour un ancien serveur utilisant un OS ne gérant pas les particularités des SSD), j'avais opté pour un SSD PATA de chez Transcend, qui est censé gérer ce genre de contraintes, justement. Maintenant, pas de stats sur des volumes suffisamment importants pour savoir si c'est réellement plus fiable ou si ça relève du simple discours commercial sans réel fondement.
Il existe sûrement des solutions plus solides, mais encore faut-il que ça soit justifiable économiquement, selon les situations.
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.
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
Dominique MICOLLET
Bonjour,
La Bete des Vosges (Francis Chartier) wrote:
Il existe sûrement des solutions plus solides, mais encore faut-il que ça soit justifiable économiquement, selon les situations.
Il existait à une époque le jffs (journalized flash file system), à ne pas confondre avec le jfs, qui était censé résoudre ce problème. Par contre, je ne l'ai jamais mis en œuvre.
Cordialement
Dominique.
Bonjour,
La Bete des Vosges (Francis Chartier) wrote:
Il existe sûrement des solutions plus solides, mais encore faut-il que ça
soit justifiable économiquement, selon les situations.
Il existait à une époque le jffs (journalized flash file system), à ne pas
confondre avec le jfs, qui était censé résoudre ce problème.
Par contre, je ne l'ai jamais mis en œuvre.
Il existe sûrement des solutions plus solides, mais encore faut-il que ça soit justifiable économiquement, selon les situations.
Il existait à une époque le jffs (journalized flash file system), à ne pas confondre avec le jfs, qui était censé résoudre ce problème. Par contre, je ne l'ai jamais mis en œuvre.
Cordialement
Dominique.
Dominique MICOLLET
Bonjour,
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
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).
Quoi qu'il en soit vous pouvez à présent matyriser tranquillement la copie.
Cordialement
Dominique
Bonjour,
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
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).
Quoi qu'il en soit vous pouvez à présent matyriser tranquillement la copie.
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
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).
Quoi qu'il en soit vous pouvez à présent matyriser tranquillement la copie.
Cordialement
Dominique
Nicolas George
Dominique MICOLLET , dans le message <5252588e$0$2043$, a écrit :
Il existait à une époque le jffs (journalized flash file system), à ne pas confondre avec le jfs, qui était censé résoudre ce problème.
À ce que je sais, JFFS(2) est prévu pour fonctionner avec des MTD, et ne peut pas utiliser un simple périphérique par blocs directement.
Dominique MICOLLET , dans le message
<5252588e$0$2043$426a74cc@news.free.fr>, a écrit :
Il existait à une époque le jffs (journalized flash file system), à ne pas
confondre avec le jfs, qui était censé résoudre ce problème.
À ce que je sais, JFFS(2) est prévu pour fonctionner avec des MTD, et ne
peut pas utiliser un simple périphérique par blocs directement.
