Input/output error

Le Sat, 30 Jan 2010 12:51:36 +0100, Thomas a écrit:

parce que j'ai acheté le macbook le moins cher il y a 2 ans et demi

Moi aussi, je viens d'essayer sur le mien et ça tourne dans les 25 Mo/S.

--
L'église est une secte qui a réussi.
Ernest Renan.

Thomas a écrit :

L'interface série permet un débit supérieur à
l'interface parallèle.

bizarre, j'ai des ordis plus vieux (chez un client) où les disques sont
en ATA au lieu de SATA, et où du coup (j'ai l'impression), le même test
va plus vite ...

Il ne faut pas confondre les performances de l'interface et du disque.
Un disque SATA 2,5" de portable tournant lentement avec des contraintes
de consommation sera certainement moins rapide qu'un disque 3,5" de
serveur tournant rapidement.

"formater bas niveau" : en quoi ça consiste, et sur quel type de disque
on le fait ?

Ça consiste à "créer" les pistes et les secteurs sur la surface
magnétique. C'est ce que fait fdformat avec une disquette.

ah bon, ça fait carrément une action presque mécanique !

C'est magnétique, mais ça consiste notamment à écrire en dehors des
zones de données (zones de synchronisation, index de pistes et de
secteurs...)

je pensais que le formatage c'était uniquement de l'écriture de données
(sur un disque deja en forme physiquement),
genre "0 espace utilisé, tant d'espace libre", le nom du disque, etc ...

Ça c'est ce qu'on appelle parfois le "formatage logique", autrement dit
l'initialisation du système de fichiers. Les notions telles que
fichiers, espace libre et espace utilisé ne concernent pas le disque
mais seulement le logiciel qui y accède. La confusion vient certainement
de la commande FORMAT de DOS qui, sur une disquette, effectuait par
défaut à la fois le formatage physique (bas niveau) et le formatage
logique. En revanche la même commande sur une partition de disque dur
n'effectue qu'un formatage logique.

if=/dev/zero qui est une source infinie de zéros. /dev/null est un
trou noir sans fond dont rien ne sort, on ne peut l'utiliser comme source.

c'est bizarre, pourquoi les 2 sont en rw ?

Ce sont les permissions d'accès des fichiers spéciaux, qui n'ont rien à
voir avec les capacités des périphériques eux-mêmes.

dd if=/dev/disk0 of=/dev/disk0 bs=1m conv=noerror,sync
pour forcer une réécriture, mais qui soit tout simplement l'écriture de
ce qu'il y avait avant, partout où c'est possible de relire,

Note : sous GNU/Linux, badblocks a un mode de lecture-écriture non
destructive pour faire ça.

ça peut être une bonne idée ?
pas de danger si on le fait sur le dd de démarrage ?

Je ne suis pas sûr que ce soit une bonne idée, il pourrait y avoir des
effets de bord. En tout cas il ne faut pas le faire avec un disque en
cours d'utilisation (par exemple contenant des systèmes de fichiers
montés, du swap ou des volumes RAID ou LVM en cours d'utilisation) car
les données pourraient être modifiées entre la lecture et la réécriture.
D'autre part ça risque de ramer un max car la tête devra faire des
aller-retour continuels.

pourquoi il faut écrire pour que le contrôleur intégré fasse son boulot,
et que lire ne suffit pas ?

Par sécurité. Une erreur de lecture peut n'être que transitoire et les
données d'un secteur réalloué sont perdues, donc le contrôleur ne
réalloue pas automatiquement un secteur illisible. Il se contente de le
marquer "pending" (on peut le voir avec SMART). Un secteur marqué
"pending" pourra être réalloué si une lecture ultérieure réussit (et les
données lues avec succès sont recopiées au nouvel emplacement) ou bien
si on écrit dedans (car les anciennes données n'ont alors plus
d'importance).

je suppose que tu m'as pas écrit tout le détail, et qu'il est assez
intelligent pour ne reallouer que s'il est sur que le secteur est
irrécupérable ?

J'ai écrit ce que je sais, et je ne connais pas le détail qui varie
probablement par constructeur, famille de disque...

par exemple, s'il veut écrire dans un secteur marqué "pending", il écrit
dedans, et il relit aussitôt pour voir s'il suffisait d'écrire à nouveau
pour que le secteur soit à nouveau lisible (et si non, il le réalloue
aussitôt puisqu'il a encore les données à écrire en mémoire) ?

C'est possible. De fait, lors de mes expérience de "réparation" de
secteurs défectueux, après réparation complète j'ai eu l'impression que
le nombre de secteurs réalloués rapporté par SMART était inférieur au
nombre initial de secteurs illisibles rapporté par badblocks. Donc
certains secteurs ont pu être réparés sans être réalloués.

en commençant le fil, j'avais en tête que le système avait la totalité
du dd à disposition, et qu'au fur et à mesure que des secteurs
devenaient défectueux, l'espace disque à disposition du système diminuait

en fait, l'espace disque à disposition du système est constant, un peu
moins grand que le dd tout entier,

tant qu'il y a assez peu de secteurs défectueux,
pour le système c'est quasi transparent, le contrôleur intégré s'occupe
de tout,

Pas toujours hélas, l'expérience le montre. Il faut aussi que les
secteurs ne deviennent pas complètement illisibles trop brutalement.

et le fabriquant est susceptible de refuser la garantie en disant que
son dd "fournit le service"

et quand il y a trop de secteurs défectueux,
l'espace disque à disposition du système ne change pas de taille, mais
il commence à y avoir des erreurs (que le contrôleur intégré ne peut
plus faire disparaître),

A ce stade fsck peut détecter et marquer les blocs défectueux pour
qu'ils ne soient plus utilisés et l'espace disponible du système de
fichiers (et non du disque) diminue.

et le fabriquant devrait accepter la garantie, parce qu'il y a des
erreurs "non resorbables"

c'est ça ? :-)

Pour la partie technique, oui. Je ne peux me prononcer en ce qui
concerne la garantie, ne l'ayant jamais fait jouer pour ce genre de défaut.

je voulais surtout éviter de faire perdre du temps à tout le monde si au
final il m'aurais dit que le disque n'est pas /assez/ abîmé et qu'il ne
fait pas marcher la garantie parce qu'il considère que le disque est en
suffisamment bon état
(c'est normal, on va pas le changer des le 1er secteur défectueux, les
secteurs de réserve sont là pour ça :-) )

Oui mais non, ils sont là pour éviter que des secteurs défectueux soient
visibles. Manifestement ça n'a pas marché.

[vérification des blocs défectueux]

Je suppose que le fsck de ton OS a quand même une option équivalente.

http://developer.apple.com/mac/library/documentation/Darwin/Reference/Man
Pages/man8/fsck.8.html
en regardant très rapidement je ne vois pas ...

Voir aussi dans la page de manuel du fsck spécifique au système de
fichiers (fsck.<fstype>, ex : fsck.ext2 pour ext2) qu'appelle fsck en
sous-main.

merci pour les nombreuses infos que je ne reprend pas toutes :-)


In article <hk1iru$1oo6$1@saria.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

Thomas a écrit :

>> if=/dev/zero qui est une source infinie de zéros. /dev/null est un
>> trou noir sans fond dont rien ne sort, on ne peut l'utiliser comme source.
>
> c'est bizarre, pourquoi les 2 sont en rw ?

Ce sont les permissions d'accès des fichiers spéciaux, qui n'ont rien à
voir avec les capacités des périphériques eux-mêmes.

ah ?
je ne comprend pas pourquoi ça n'a rien à voir, justement,
mais bon tant pis, je comprendrai plus tard

> dd if=/dev/disk0 of=/dev/disk0 bs=1m conv=noerror,sync
> pour forcer une réécriture, mais qui soit tout simplement l'écriture de
> ce qu'il y avait avant, partout où c'est possible de relire,

Note : sous GNU/Linux, badblocks a un mode de lecture-écriture non
destructive pour faire ça.

"un mode de lecture-écriture non destructive",
ça veut dire que ça lit le maximum de données dans un secteur défectueux
avant de réécrire au même endroit ?
l'outil est obligé d'écrire un bloc d'un coup, et pas un octet ?
(bloc = secteur ?)

de toutes façons j'ai pas badblocks et je sais pas si l'équivalent existe

> ça peut être une bonne idée ?
> pas de danger si on le fait sur le dd de démarrage ?

Je ne suis pas sûr que ce soit une bonne idée, il pourrait y avoir des
effets de bord. En tout cas il ne faut pas le faire avec un disque en
cours d'utilisation (par exemple contenant des systèmes de fichiers
montés, du swap ou des volumes RAID ou LVM en cours d'utilisation) car
les données pourraient être modifiées entre la lecture et la réécriture.

le pb c'est que c'est mon disque de démarrage qui est abîmé

D'autre part ça risque de ramer un max car la tête devra faire des
aller-retour continuels.

mais je fais en sorte de ne *rien* faire d'autre pendant l'opération,
pour limiter ce genre d'inconvenient


si je fais de la "chirurgie" du genre
dd if=/dev/disk0 of=/dev/disk0 bs=1 conv=noerror,sync count=1
skip8961152

que ce soit sur des octets lisibles ou pas, il y a certainement d'autres
octets du même bloc qui sont lisibles,
est ce que le contrôleur intégré va chercher tous les octets du bloc qui
sont lisibles pour les recopier, s'il décide de reallouer, même si on
fait juste une opération d'écriture (sur 1 octet),
ou ils risquent d'être perdus ?


si je fais ça uniquement sur des octets illisibles

+ su moi -c 'sudo dd if=/dev/disk0 of=/dev/null bs=1 count=1
skip9234560'
Password:
Password:
dd: /dev/disk0: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 10.766783 secs (0 bytes/sec)

normalement il n'y a pas grand risque ?
cad, même si c'est un endroit sensible du système, de toutes façons,
comme c'est abîmé, il risque d'y avoir des pbs, donc autant essayer de
réparer

> en commençant le fil, j'avais en tête que le système avait la totalité
> du dd à disposition, et qu'au fur et à mesure que des secteurs
> devenaient défectueux, l'espace disque à disposition du système diminuait
>
> en fait, l'espace disque à disposition du système est constant, un peu
> moins grand que le dd tout entier,
>
> tant qu'il y a assez peu de secteurs défectueux,
> pour le système c'est quasi transparent, le contrôleur intégré s'occupe
> de tout,

Pas toujours hélas, l'expérience le montre. Il faut aussi que les
secteurs ne deviennent pas complètement illisibles trop brutalement.

"quasi", c'était pour prendre ça en compte, le temps que le contrôleur
intégré décide de reallouer

> et le fabriquant devrait accepter la garantie, parce qu'il y a des
> erreurs "non resorbables"
>
> c'est ça ? :-)

Pour la partie technique, oui.

merci :-)

Je ne peux me prononcer en ce qui
concerne la garantie, ne l'ayant jamais fait jouer pour ce genre de défaut.

bon, ben je vais faire comme si c'était ça, et on verra bien ce qu'on me
répond :-)

> je voulais surtout éviter de faire perdre du temps à tout le monde si au
> final il m'aurais dit que le disque n'est pas /assez/ abîmé et qu'il ne
> fait pas marcher la garantie parce qu'il considère que le disque est en
> suffisamment bon état
> (c'est normal, on va pas le changer des le 1er secteur défectueux, les
> secteurs de réserve sont là pour ça :-) )

Oui mais non, ils sont là pour éviter que des secteurs défectueux soient
visibles. Manifestement ça n'a pas marché.

j'ai pas bien compris cette phrase :
je pense avoir compris le reste mais ça ne colle pas avec celle ci

"Manifestement ça n'a pas marché" :
dans mon cas à moi parce que j'ai des erreurs ?
ou parce que d'une façon générale ça ne marche pas aussi bien que prévu
à la conception ?

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/

In article
<fantome.forums.tDeContes-024D92.17042824012010@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

In article
<fantome.forums.tDeContes-FF61FE.14210024012010@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> In article <hjfl7j$1khe$1@saria.nerim.net>,
> Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
>
> > Thomas a écrit :
> >
> > > sudo dd if=/dev/disk0 of=/dev/null bs48576
> > > dd: /dev/disk0: Input/output error
> > > 77579+0 records in
> > > 77579+0 records out
> > > 81347477504 bytes transferred in 5809.144533 secs (14003349 bytes/sec)
> > >
> > > il indique toutes les erreurs, ou il s'arrête à la 1ere, comme cat ?
> >
> > Le dd de GNU a besoin de l'option conv=noerror pour continuer après une
> > erreur de lecture.
>
> merci bcp :-)
> en lisant man dd j'ai vu qu'il y a aussi une option permettant de ne pas
> recommencer depuis le début :-)

pour info :

qu'est ce qui fait que dd va essayer de relire 3, 7, ou 50 fois le même
octet ?


+ su moi -c 'sudo dd if=/dev/disk0s3 of=/dev/null bs=1 conv=noerror
count skip8961152'
Password:
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 10.787837 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 21.576977 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 32.366094 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 43.243993 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 54.033119 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 64.855713 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 75.766689 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 86.555716 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 97.356123 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 108.145065 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 118.956730 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 129.745716 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 140.579010 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 151.390399 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 162.212788 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 173.012956 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 183.824590 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 194.614025 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 205.435838 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 216.225026 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 227.014053 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 237.803346 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 248.614659 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 259.404427 secs (0 bytes/sec)
dd: /dev/disk0s3: Input/output error
10+0 records in
10+0 records out
10 bytes transferred in 269.408825 secs (0 bytes/sec)

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/

bon, là ça fait pas encore tout à fait 2 mois que mon ordi est revenu de
réparation, et le smart est passé au rouge !
donc au moins je devrais pas avoir de soucis par rapport au fait qu'ils
acceptent de le changer :-)

(seagate c'est une bonne marque ?
ils ne m'ont pas roulé en me mettant un disque bas de gamme ?
j'ai pas eu de chance et je suis tombé sur une pièce défectueuse ?)



mais puisque je suis dedans, je voulais creuser un petit peu le
fonctionnement de dd :


In article
<fantome.forums.tDeContes-9ECCBA.04083931012010@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> > dd if=/dev/disk0 of=/dev/disk0 bs=1m conv=noerror,sync
> > pour forcer une réécriture, mais qui soit tout simplement l'écriture de
> > ce qu'il y avait avant, partout où c'est possible de relire,

> > ça peut être une bonne idée ?
> > pas de danger si on le fait sur le dd de démarrage ?
>
> Je ne suis pas sûr que ce soit une bonne idée, il pourrait y avoir des
> effets de bord. En tout cas il ne faut pas le faire avec un disque en
> cours d'utilisation (par exemple contenant des systèmes de fichiers
> montés, du swap ou des volumes RAID ou LVM en cours d'utilisation) car
> les données pourraient être modifiées entre la lecture et la réécriture.

le pb c'est que c'est mon disque de démarrage qui est abîmé

> D'autre part ça risque de ramer un max car la tête devra faire des
> aller-retour continuels.

mais je fais en sorte de ne *rien* faire d'autre pendant l'opération,
pour limiter ce genre d'inconvenient


si je fais de la "chirurgie" du genre
dd if=/dev/disk0 of=/dev/disk0 bs=1 conv=noerror,sync count=1
skip8961152

que ce soit sur des octets lisibles ou pas, il y a certainement d'autres
octets du même bloc qui sont lisibles,
est ce que le contrôleur intégré va chercher tous les octets du bloc qui
sont lisibles pour les recopier, s'il décide de reallouer, même si on
fait juste une opération d'écriture (sur 1 octet),
ou ils risquent d'être perdus ?


si je fais ça uniquement sur des octets illisibles

+ su moi -c 'sudo dd if=/dev/disk0 of=/dev/null bs=1 count=1
skip9234560'
Password:
Password:
dd: /dev/disk0: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 10.766783 secs (0 bytes/sec)

normalement il n'y a pas grand risque ?
cad, même si c'est un endroit sensible du système, de toutes façons,
comme c'est abîmé, il risque d'y avoir des pbs, donc autant essayer de
réparer

+ su moi -c 'sudo dd if=/dev/disk0s3 of=/dev/disk0s3 bs=1
conv=noerror,sync'
Password:
dd: /dev/disk0s3: Input/output error
119234560+0 records in
119234560+0 records out
119234560 bytes transferred in 772.527031 secs (154344 bytes/sec)
dd: /dev/disk0s3: Input/output error
dd: /dev/disk0s3: Input/output error
119234561+0 records in
119234560+0 records out
119234560 bytes transferred in 783.349511 secs (152211 bytes/sec)

et c'est tout

pourquoi il s'arrête là ??
je devine que ça n'est pas étranger au fait (probable) qu'à cet endroit
il y a un secteur défectueux qui n'a pas pu être remplacé,
mais, avec l'option "conv=noerror,sync", il n'est pas censé continuer
"tout droit" dans /tous/ les cas ?

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/

Le Tue, 02 Feb 2010 03:00:23 +0100, Thomas a écrit:

(seagate c'est une bonne marque ?

Oui mais ces derniers mois la qualité a nettement baissé.

ils ne m'ont pas roulé en me mettant un disque bas de gamme ? j'ai pas
eu de chance et je suis tombé sur une pièce défectueuse ?)

Il y a environ 3% de disques qui tombent en panne chaque année. Si tu
n'en manipule pas des centaines (mon cas) c'est juste une loterie...

--
Measuring programming progress by lines of code is like measuring
aircraft building progress by weight.
Bill Gates