il y a qqes fichiers (simples fichiers textes) que je n'arrive pas à
ouvrir avec des logiciels
alors j'ai fait
cat fichier
pour voir,
et ça affiche le début du fichier, ça s'arrête avant la fin, et
cat: fichier: Input/output error
:-(
qu'est ce qu'il se passe ?
j'ai fait marcher l'utilitaire de disques avec sos disque, je pense
qu'il fait tourner fsck en dessous, et pour lui tout va bien
ça scannera tout le disque au lieu de juste la partition, donc c'est encore mieux ?
Oui, mais c'est plus long.
voilà... S'il y a une erreur, formatage bas niveau ou retour au fabricant selon ton humeur.
On ne peut pas formater bas niveau un disque ATA. On peut juste écrire partout dessus en espérant soit "remettre en forme" les secteurs défectueux, soit les faire réallouer par le contrôleur intégré.
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.
est ce que des qu'on a une erreur de ce type on peut faire marcher la garantie ?
A voir si le programme de test constructeur propose un test de surface et fournit un code RMA en cas d'échec.
ou alors, est ce que ça veut juste dire qu'il y a 1 bloc défectueux, le fs va faire en sorte de ne plus l'utiliser
Le système de fichiers ne fait pas forcément ça automatiquement. Par exemple sous GNU/Linux avec ext2 il faut exécuter fsck avec l'option -c (qui utilise badblocks en sous-main).
Thomas a écrit :
ça scannera tout le disque au lieu de juste la partition, donc c'est
encore mieux ?
Oui, mais c'est plus long.
voilà... S'il y a une erreur, formatage bas niveau ou retour au fabricant
selon ton humeur.
On ne peut pas formater bas niveau un disque ATA. On peut juste écrire
partout dessus en espérant soit "remettre en forme" les secteurs
défectueux, soit les faire réallouer par le contrôleur intégré.
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.
est ce que des qu'on a une erreur de ce type on peut faire marcher la
garantie ?
A voir si le programme de test constructeur propose un test de surface
et fournit un code RMA en cas d'échec.
ou alors, est ce que ça veut juste dire qu'il y a 1 bloc défectueux, le
fs va faire en sorte de ne plus l'utiliser
Le système de fichiers ne fait pas forcément ça automatiquement. Par
exemple sous GNU/Linux avec ext2 il faut exécuter fsck avec l'option -c
(qui utilise badblocks en sous-main).
ça scannera tout le disque au lieu de juste la partition, donc c'est encore mieux ?
Oui, mais c'est plus long.
voilà... S'il y a une erreur, formatage bas niveau ou retour au fabricant selon ton humeur.
On ne peut pas formater bas niveau un disque ATA. On peut juste écrire partout dessus en espérant soit "remettre en forme" les secteurs défectueux, soit les faire réallouer par le contrôleur intégré.
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.
est ce que des qu'on a une erreur de ce type on peut faire marcher la garantie ?
A voir si le programme de test constructeur propose un test de surface et fournit un code RMA en cas d'échec.
ou alors, est ce que ça veut juste dire qu'il y a 1 bloc défectueux, le fs va faire en sorte de ne plus l'utiliser
Le système de fichiers ne fait pas forcément ça automatiquement. Par exemple sous GNU/Linux avec ext2 il faut exécuter fsck avec l'option -c (qui utilise badblocks en sous-main).
Stephane CHAZELAS
2010-01-23, 21:12(+01), Pascal Hambourg: [...]
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.
[...]
Le dd de POSIX (http://www.opengroup.org/onlinepubs/9699919799/utilities/dd.html) et le dd de Unix V6 (1975, j'etais pas né http://minnie.tuhs.org/UnixTree/V6/usr/man/man1/dd.1.html) aussi.
D'ailleurs, on devrait pratiquement toujours l'utiliser (avec sync, enfin surtout synx) quand on manipule des raw block devices (en particulier pour copies, backups...).
-- Stéphane
2010-01-23, 21:12(+01), Pascal Hambourg:
[...]
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.
[...]
Le dd de POSIX
(http://www.opengroup.org/onlinepubs/9699919799/utilities/dd.html)
et le dd de Unix V6 (1975, j'etais pas né
http://minnie.tuhs.org/UnixTree/V6/usr/man/man1/dd.1.html)
aussi.
D'ailleurs, on devrait pratiquement toujours l'utiliser (avec
sync, enfin surtout synx) quand on manipule des raw block
devices (en particulier pour copies, backups...).
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.
[...]
Le dd de POSIX (http://www.opengroup.org/onlinepubs/9699919799/utilities/dd.html) et le dd de Unix V6 (1975, j'etais pas né http://minnie.tuhs.org/UnixTree/V6/usr/man/man1/dd.1.html) aussi.
D'ailleurs, on devrait pratiquement toujours l'utiliser (avec sync, enfin surtout synx) quand on manipule des raw block devices (en particulier pour copies, backups...).
-- Stéphane
Pascal Hambourg
Stephane CHAZELAS a écrit :
2010-01-23, 21:12(+01), Pascal Hambourg:
Le dd de GNU a besoin de l'option conv=noerror pour continuer après une erreur de lecture.
Le dd de POSIX et le dd de Unix V6 aussi.
Ne connaissant que GNU/Linux parmi les Unix, je me méfie.
D'ailleurs, on devrait pratiquement toujours l'utiliser (avec sync, enfin surtout synx) quand on manipule des raw block devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ? Si je comprends bien, sync évite de décaler les données suivant un bloc illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie s'arrête au bloc illisible.
Stephane CHAZELAS a écrit :
2010-01-23, 21:12(+01), Pascal Hambourg:
Le dd de GNU a besoin de l'option conv=noerror pour continuer après une
erreur de lecture.
Le dd de POSIX et le dd de Unix V6 aussi.
Ne connaissant que GNU/Linux parmi les Unix, je me méfie.
D'ailleurs, on devrait pratiquement toujours l'utiliser (avec
sync, enfin surtout synx) quand on manipule des raw block
devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ?
Si je comprends bien, sync évite de décaler les données suivant un bloc
illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie
s'arrête au bloc illisible.
Le dd de GNU a besoin de l'option conv=noerror pour continuer après une erreur de lecture.
Le dd de POSIX et le dd de Unix V6 aussi.
Ne connaissant que GNU/Linux parmi les Unix, je me méfie.
D'ailleurs, on devrait pratiquement toujours l'utiliser (avec sync, enfin surtout synx) quand on manipule des raw block devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ? Si je comprends bien, sync évite de décaler les données suivant un bloc illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie s'arrête au bloc illisible.
Paul Gaborit
À (at) Sat, 23 Jan 2010 20:57:45 +0100, Pascal Hambourg écrivait (wrote):
Thomas a écrit :
Pascal Hambourg wrote:
comment font-elles le fsck de la racine au démarrage ?
je crois qu'il est fait juste avant le montage, précisément :-)
Comment font-elles ? Pas avec le fsck qui est sur la racine en tout cas.
Le montage initial est en "read only" et ne bloque pas la ressource.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 23 Jan 2010 20:57:45 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait (wrote):
À (at) Sat, 23 Jan 2010 20:57:45 +0100, Pascal Hambourg écrivait (wrote):
Thomas a écrit :
Pascal Hambourg wrote:
comment font-elles le fsck de la racine au démarrage ?
je crois qu'il est fait juste avant le montage, précisément :-)
Comment font-elles ? Pas avec le fsck qui est sur la racine en tout cas.
Le montage initial est en "read only" et ne bloque pas la ressource.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Thomas
In article <hjfkbp$1k9a$, Pascal Hambourg wrote:
Thomas a écrit : > Pascal Hambourg wrote: > >> Nicolas George a écrit : >>> N'y a-t-il pas des variantes d'Unix qui se réservent de manière exclusive >>> l'accès à un device monté ? >> Aucune idée, je n'y avais pas pensé. Dans quel intérêt ? Si c'est juste >> pour empêcher root de faire une grosse connerie, ça me paraît un peu >> limité dans la mesure où root a bien d'autre moyens d'en faire. > > pourtant ... > > + su moi -c 'sudo dd if=/dev/disk1s2 of=/dev/null bs48576' > Password: > dd: /dev/disk1s2: Resource busy
Je n'ai pas écrit que ça n'existait pas mais que je n'en voyais pas l'intérêt.
ah bon, alors sous linux c'est comme tu dis ? moi ça me parait plus logique comme ça note que tout ce que tu as dit reste valable pour disk0
>> Et puis >> comment font-elles le fsck de la racine au démarrage ? > > je crois qu'il est fait juste avant le montage, précisément :-)
Comment font-elles ? Pas avec le fsck qui est sur la racine en tout cas.
et comment marche le mode "single user" ? (sur mac c'est en appuyant sur pomme-s au démarrage, je suppose qu'il y a l'équivalent sous linux)
sur mac, dans ce mode on nous propose de faire fsck, *puis* de monter la partition si on veut faire des opérations dessus
> à propos, qqn sait s'il est fait sur disk0s2 ou sur disk0 ?
fsck travaillant sur un système de fichiers, cela dépend si le système de fichiers est dans une partition ou un disque entier.
ok ah, c'est possible de mettre le fs directement sur le disque, sans partition ? je croyais que la partition était obligatoire
au fait, à quoi sert disk0s1 ? ça prend quand même, apparemment, 200 Mo quelle que soit la taille du dd, c'est pas négligeable ...
In article <hjfkbp$1k9a$1@saria.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Thomas a écrit :
> Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
>
>> Nicolas George a écrit :
>>> N'y a-t-il pas des variantes d'Unix qui se réservent de manière exclusive
>>> l'accès à un device monté ?
>> Aucune idée, je n'y avais pas pensé. Dans quel intérêt ? Si c'est juste
>> pour empêcher root de faire une grosse connerie, ça me paraît un peu
>> limité dans la mesure où root a bien d'autre moyens d'en faire.
>
> pourtant ...
>
> + su moi -c 'sudo dd if=/dev/disk1s2 of=/dev/null bs48576'
> Password:
> dd: /dev/disk1s2: Resource busy
Je n'ai pas écrit que ça n'existait pas mais que je n'en voyais pas
l'intérêt.
ah bon, alors sous linux c'est comme tu dis ? moi ça me parait plus
logique comme ça
note que tout ce que tu as dit reste valable pour disk0
>> Et puis
>> comment font-elles le fsck de la racine au démarrage ?
>
> je crois qu'il est fait juste avant le montage, précisément :-)
Comment font-elles ? Pas avec le fsck qui est sur la racine en tout cas.
et comment marche le mode "single user" ?
(sur mac c'est en appuyant sur pomme-s au démarrage, je suppose qu'il y
a l'équivalent sous linux)
sur mac, dans ce mode on nous propose de faire fsck, *puis* de monter la
partition si on veut faire des opérations dessus
> à propos, qqn sait s'il est fait sur disk0s2 ou sur disk0 ?
fsck travaillant sur un système de fichiers, cela dépend si le système
de fichiers est dans une partition ou un disque entier.
ok
ah, c'est possible de mettre le fs directement sur le disque, sans
partition ? je croyais que la partition était obligatoire
au fait, à quoi sert disk0s1 ?
ça prend quand même, apparemment, 200 Mo quelle que soit la taille du dd,
c'est pas négligeable ...
Thomas a écrit : > Pascal Hambourg wrote: > >> Nicolas George a écrit : >>> N'y a-t-il pas des variantes d'Unix qui se réservent de manière exclusive >>> l'accès à un device monté ? >> Aucune idée, je n'y avais pas pensé. Dans quel intérêt ? Si c'est juste >> pour empêcher root de faire une grosse connerie, ça me paraît un peu >> limité dans la mesure où root a bien d'autre moyens d'en faire. > > pourtant ... > > + su moi -c 'sudo dd if=/dev/disk1s2 of=/dev/null bs48576' > Password: > dd: /dev/disk1s2: Resource busy
Je n'ai pas écrit que ça n'existait pas mais que je n'en voyais pas l'intérêt.
ah bon, alors sous linux c'est comme tu dis ? moi ça me parait plus logique comme ça note que tout ce que tu as dit reste valable pour disk0
>> Et puis >> comment font-elles le fsck de la racine au démarrage ? > > je crois qu'il est fait juste avant le montage, précisément :-)
Comment font-elles ? Pas avec le fsck qui est sur la racine en tout cas.
et comment marche le mode "single user" ? (sur mac c'est en appuyant sur pomme-s au démarrage, je suppose qu'il y a l'équivalent sous linux)
sur mac, dans ce mode on nous propose de faire fsck, *puis* de monter la partition si on veut faire des opérations dessus
> à propos, qqn sait s'il est fait sur disk0s2 ou sur disk0 ?
fsck travaillant sur un système de fichiers, cela dépend si le système de fichiers est dans une partition ou un disque entier.
ok ah, c'est possible de mettre le fs directement sur le disque, sans partition ? je croyais que la partition était obligatoire
au fait, à quoi sert disk0s1 ? ça prend quand même, apparemment, 200 Mo quelle que soit la taille du dd, c'est pas négligeable ...
> D'ailleurs, on devrait pratiquement toujours l'utiliser (avec > sync, enfin surtout synx) quand on manipule des raw block > devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ? Si je comprends bien, sync évite de décaler les données suivant un bloc illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie s'arrête au bloc illisible.
pas "surtout sync", il a écrit "noerror, avec sync, enfin surtout synx"
In article <hjfqf1$1me9$1@saria.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Stephane CHAZELAS a écrit :
> D'ailleurs, on devrait pratiquement toujours l'utiliser (avec
> sync, enfin surtout synx) quand on manipule des raw block
> devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ?
Si je comprends bien, sync évite de décaler les données suivant un bloc
illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie
s'arrête au bloc illisible.
pas "surtout sync",
il a écrit "noerror, avec sync, enfin surtout synx"
> D'ailleurs, on devrait pratiquement toujours l'utiliser (avec > sync, enfin surtout synx) quand on manipule des raw block > devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ? Si je comprends bien, sync évite de décaler les données suivant un bloc illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie s'arrête au bloc illisible.
pas "surtout sync", il a écrit "noerror, avec sync, enfin surtout synx"
> D'ailleurs, on devrait pratiquement toujours l'utiliser (avec > sync, enfin surtout synx) quand on manipule des raw block > devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ? Si je comprends bien, sync évite de décaler les données suivant un bloc illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie s'arrête au bloc illisible.
pas "surtout sync", il a écrit "noerror, avec sync, enfin surtout synx"
ça fait quoi, synx ? moi je l'ai pas
Laissez tomber, c'est la fatigue... Je crois que ce que j'ai voulu essayer de dire, c'est qu'il ne fallait surtout pas oublier "sync", si on utilisait "noerror". Attention avec sync, si on utilise des pipes toutefois.
-- Stéphane
2010-01-24, 13:32(+01), Thomas:
In article <hjfqf1$1me9$1@saria.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Stephane CHAZELAS a écrit :
> D'ailleurs, on devrait pratiquement toujours l'utiliser (avec
> sync, enfin surtout synx) quand on manipule des raw block
> devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ?
Si je comprends bien, sync évite de décaler les données suivant un bloc
illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie
s'arrête au bloc illisible.
pas "surtout sync",
il a écrit "noerror, avec sync, enfin surtout synx"
ça fait quoi, synx ? moi je l'ai pas
Laissez tomber, c'est la fatigue... Je crois que ce que j'ai
voulu essayer de dire, c'est qu'il ne fallait surtout pas
oublier "sync", si on utilisait "noerror". Attention avec sync,
si on utilise des pipes toutefois.
> D'ailleurs, on devrait pratiquement toujours l'utiliser (avec > sync, enfin surtout synx) quand on manipule des raw block > devices (en particulier pour copies, backups...).
Pourquoi "surtout sync" ? Si je comprends bien, sync évite de décaler les données suivant un bloc illisible, mais ça n'a guère d'intérêt sans noerror puisque la copie s'arrête au bloc illisible.
pas "surtout sync", il a écrit "noerror, avec sync, enfin surtout synx"
ça fait quoi, synx ? moi je l'ai pas
Laissez tomber, c'est la fatigue... Je crois que ce que j'ai voulu essayer de dire, c'est qu'il ne fallait surtout pas oublier "sync", si on utilisait "noerror". Attention avec sync, si on utilise des pipes toutefois.
-- Stéphane
Thomas
In article <hjfl7j$1khe$, Pascal Hambourg wrote:
Thomas a écrit : > > ça scannera tout le disque au lieu de juste la partition, donc c'est > encore mieux ?
Oui, mais c'est plus long.
si la partition prend presque tout le disque, c'est pas bcp plus long,
et s'il s'agit de vérifier l'état physique du disque, autant le faire en entier, non ?
(j'ai posé la question pour être sur que j'avais pas compris de travers)
>> voilà... S'il y a une erreur, formatage bas niveau ou retour au fabricant >> selon ton humeur.
On ne peut pas formater bas niveau un disque ATA.
ATA séries c'est SATA ? et c'est pareil ?
(à propos, c'est connu que SATA c'est plus lent que ATA ?)
"formater bas niveau" : en quoi ça consiste, et sur quel type de disque on le fait ?
On peut juste écrire partout dessus
dd if=/dev/null of=/dev/disk0 bs48576 ?
en espérant soit "remettre en forme" les secteurs défectueux,
qu'appelles tu "remettre en forme" ? parce que s'il y a un pb physique, je ne vois pas comment il peut être résolu par logiciel ...
soit les faire réallouer par le contrôleur intégré.
ah oui c'est ça, c'est pas le fs, c'est le contrôleur intégré
pourquoi il faut écrire pour que le contrôleur intégré fasse son boulot, et que lire ne suffit pas ?
si on se place du point de vue du système, le contrôleur intégré, c'est du matériel ?
du coup, si on a un disque en très mauvais état, mais que le contrôleur intégré a fait son boulot partout, en lisant /dev/disk0 on ne verra aucun problème ?
> 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 :-)
> est ce que des qu'on a une erreur de ce type on peut faire marcher la > garantie ?
A voir si le programme de test constructeur propose un test de surface et fournit un code RMA en cas d'échec.
Modèle : ST9100824AS ST pour segate ?
a priori j'ai qu'à me retourner vers mon fournisseur qui me dira quoi, mais bon mon fournisseur c'est la fnac (et puis même), donc je préfère savoir si ça sert à rien d'y retourner tout de suite, et le pb c'est que j'ai pas de relation avec le constructeur, je sais même pas qui c'est (c'est quoi un code RMA ?)
> ou alors, est ce que ça veut juste dire qu'il y a 1 bloc défectueux, le > fs va faire en sorte de ne plus l'utiliser
Le système de fichiers ne fait pas forcément ça automatiquement. Par exemple sous GNU/Linux avec ext2 il faut exécuter fsck avec l'option -c (qui utilise badblocks en sous-main).
chez moi cette option fait autre chose mais a priori j'ai confondu avec le contrôleur intégré
In article <hjfl7j$1khe$1@saria.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Thomas a écrit :
>
> ça scannera tout le disque au lieu de juste la partition, donc c'est
> encore mieux ?
Oui, mais c'est plus long.
si la partition prend presque tout le disque, c'est pas bcp plus long,
et s'il s'agit de vérifier l'état physique du disque, autant le faire en
entier, non ?
(j'ai posé la question pour être sur que j'avais pas compris de travers)
>> voilà... S'il y a une erreur, formatage bas niveau ou retour au fabricant
>> selon ton humeur.
On ne peut pas formater bas niveau un disque ATA.
ATA séries c'est SATA ? et c'est pareil ?
(à propos, c'est connu que SATA c'est plus lent que ATA ?)
"formater bas niveau" : en quoi ça consiste, et sur quel type de disque
on le fait ?
On peut juste écrire
partout dessus
dd if=/dev/null of=/dev/disk0 bs48576
?
en espérant soit "remettre en forme" les secteurs
défectueux,
qu'appelles tu "remettre en forme" ?
parce que s'il y a un pb physique, je ne vois pas comment il peut être
résolu par logiciel ...
soit les faire réallouer par le contrôleur intégré.
ah oui c'est ça, c'est pas le fs, c'est le contrôleur intégré
pourquoi il faut écrire pour que le contrôleur intégré fasse son boulot,
et que lire ne suffit pas ?
si on se place du point de vue du système,
le contrôleur intégré, c'est du matériel ?
du coup, si on a un disque en très mauvais état, mais que le contrôleur
intégré a fait son boulot partout,
en lisant /dev/disk0 on ne verra aucun problème ?
> 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 :-)
> est ce que des qu'on a une erreur de ce type on peut faire marcher la
> garantie ?
A voir si le programme de test constructeur propose un test de surface
et fournit un code RMA en cas d'échec.
Modèle : ST9100824AS
ST pour segate ?
a priori j'ai qu'à me retourner vers mon fournisseur qui me dira quoi,
mais bon mon fournisseur c'est la fnac (et puis même),
donc je préfère savoir si ça sert à rien d'y retourner tout de suite, et
le pb c'est que j'ai pas de relation avec le constructeur, je sais même
pas qui c'est
(c'est quoi un code RMA ?)
> ou alors, est ce que ça veut juste dire qu'il y a 1 bloc défectueux, le
> fs va faire en sorte de ne plus l'utiliser
Le système de fichiers ne fait pas forcément ça automatiquement. Par
exemple sous GNU/Linux avec ext2 il faut exécuter fsck avec l'option -c
(qui utilise badblocks en sous-main).
chez moi cette option fait autre chose
mais a priori j'ai confondu avec le contrôleur intégré
Thomas a écrit : > > ça scannera tout le disque au lieu de juste la partition, donc c'est > encore mieux ?
Oui, mais c'est plus long.
si la partition prend presque tout le disque, c'est pas bcp plus long,
et s'il s'agit de vérifier l'état physique du disque, autant le faire en entier, non ?
(j'ai posé la question pour être sur que j'avais pas compris de travers)
>> voilà... S'il y a une erreur, formatage bas niveau ou retour au fabricant >> selon ton humeur.
On ne peut pas formater bas niveau un disque ATA.
ATA séries c'est SATA ? et c'est pareil ?
(à propos, c'est connu que SATA c'est plus lent que ATA ?)
"formater bas niveau" : en quoi ça consiste, et sur quel type de disque on le fait ?
On peut juste écrire partout dessus
dd if=/dev/null of=/dev/disk0 bs48576 ?
en espérant soit "remettre en forme" les secteurs défectueux,
qu'appelles tu "remettre en forme" ? parce que s'il y a un pb physique, je ne vois pas comment il peut être résolu par logiciel ...
soit les faire réallouer par le contrôleur intégré.
ah oui c'est ça, c'est pas le fs, c'est le contrôleur intégré
pourquoi il faut écrire pour que le contrôleur intégré fasse son boulot, et que lire ne suffit pas ?
si on se place du point de vue du système, le contrôleur intégré, c'est du matériel ?
du coup, si on a un disque en très mauvais état, mais que le contrôleur intégré a fait son boulot partout, en lisant /dev/disk0 on ne verra aucun problème ?
> 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 :-)
> est ce que des qu'on a une erreur de ce type on peut faire marcher la > garantie ?
A voir si le programme de test constructeur propose un test de surface et fournit un code RMA en cas d'échec.
Modèle : ST9100824AS ST pour segate ?
a priori j'ai qu'à me retourner vers mon fournisseur qui me dira quoi, mais bon mon fournisseur c'est la fnac (et puis même), donc je préfère savoir si ça sert à rien d'y retourner tout de suite, et le pb c'est que j'ai pas de relation avec le constructeur, je sais même pas qui c'est (c'est quoi un code RMA ?)
> ou alors, est ce que ça veut juste dire qu'il y a 1 bloc défectueux, le > fs va faire en sorte de ne plus l'utiliser
Le système de fichiers ne fait pas forcément ça automatiquement. Par exemple sous GNU/Linux avec ext2 il faut exécuter fsck avec l'option -c (qui utilise badblocks en sous-main).
chez moi cette option fait autre chose mais a priori j'ai confondu avec le contrôleur intégré
pourquoi il faut écrire pour que le contrôleur intégré fasse son boulot, et que lire ne suffit pas ?
Je vais peut-être dire une grosse bêtise, mais il me semble que quand tu lis, de toutes façons le contrôleur ne peut pas retrouver le valeur des octets perdus, alors que quand tu écris, s'il ré-alloue juste avant d'écrire, il peut faire en sorte que l'écriture de passe bien. Du coup ça me paraît logique qu'il ré-alloue à l'écriture mais pas forcément à la lecture.
si on se place du point de vue du système, le contrôleur intégré, c'est du matériel ?
Il me semble bien que oui.
du coup, si on a un disque en très mauvais état, mais que le contrôleur intégré a fait son boulot partout, en lisant /dev/disk0 on ne verra aucun problème ?
Pas si la défaillance a eu lieu entre la dernière écriture et le moment où on essaie de relire. Le contrôleur ne peut rien à ce niveau-là, c'est plutôt du RAID qu'il faut si on veut diminier la probabilité de perdre des données ainsi.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Thomas scripsit :
pourquoi il faut écrire pour que le contrôleur intégré fasse son boulot,
et que lire ne suffit pas ?
Je vais peut-être dire une grosse bêtise, mais il me semble que quand tu
lis, de toutes façons le contrôleur ne peut pas retrouver le valeur des
octets perdus, alors que quand tu écris, s'il ré-alloue juste avant
d'écrire, il peut faire en sorte que l'écriture de passe bien. Du coup
ça me paraît logique qu'il ré-alloue à l'écriture mais pas forcément à
la lecture.
si on se place du point de vue du système,
le contrôleur intégré, c'est du matériel ?
Il me semble bien que oui.
du coup, si on a un disque en très mauvais état, mais que le contrôleur
intégré a fait son boulot partout,
en lisant /dev/disk0 on ne verra aucun problème ?
Pas si la défaillance a eu lieu entre la dernière écriture et le moment
où on essaie de relire. Le contrôleur ne peut rien à ce niveau-là, c'est
plutôt du RAID qu'il faut si on veut diminier la probabilité de perdre
des données ainsi.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
pourquoi il faut écrire pour que le contrôleur intégré fasse son boulot, et que lire ne suffit pas ?
Je vais peut-être dire une grosse bêtise, mais il me semble que quand tu lis, de toutes façons le contrôleur ne peut pas retrouver le valeur des octets perdus, alors que quand tu écris, s'il ré-alloue juste avant d'écrire, il peut faire en sorte que l'écriture de passe bien. Du coup ça me paraît logique qu'il ré-alloue à l'écriture mais pas forcément à la lecture.
si on se place du point de vue du système, le contrôleur intégré, c'est du matériel ?
Il me semble bien que oui.
du coup, si on a un disque en très mauvais état, mais que le contrôleur intégré a fait son boulot partout, en lisant /dev/disk0 on ne verra aucun problème ?
Pas si la défaillance a eu lieu entre la dernière écriture et le moment où on essaie de relire. Le contrôleur ne peut rien à ce niveau-là, c'est plutôt du RAID qu'il faut si on veut diminier la probabilité de perdre des données ainsi.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
