Problème disque dur USB

Le
Louis-Philippe Gauthier
Bonjour,

J'ai un soucis avec un disque dur USB externe Seagate GoFlex de 1To.

J'ai fait un badlocks en root

# badblocks -v /dev/sdc
Vérification des blocs 0 à 976762582
Vérification des blocs défectueux (test en mode lecture seule) :
complété
Passe complétée, 5 blocs défectueux repérés.

Il m'a répertorié 5 blocs défectueux. Est-ce qu'il y a quelque chose =
à
faire par la suite ?
Refaire le test en mode écriture non-destructif (des données ;-) ?
Les blocs défectueux sont indexés et ne seront pas utilisé ?


Cordialement,


--
Louis-Philippe Gauthier

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAMzw4gXTNKoSYU6b1WNRUOK_E=Wv&tFzaZZy4=H+m4eOa6aA@mail.gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bzzz
Le #25135152
On Sun, 13 Jan 2013 10:49:42 -0500
Louis-Philippe Gauthier
J'ai fait un badlocks en root



Comme indiqué dans le man, badblocks n'est pas fait pour
être utilisé directement.

# badblocks -v /dev/sdc
Vérification des blocs 0 à 976762582
Vérification des blocs défectueux (test en mode lecture seule)  :
complété
Passe complétée, 5 blocs défectueux repérés.



5 blocs sur... 976 millions, ça reste correct.

Refaire le test en mode écriture non-destructif (des données ;- ) ?



Quel intérêt? À moins que le HD n'ait déjà un cert ain âge.

Les blocs défectueux sont indexés et ne seront pas utilisé ?



Ça, c'est ce que se serait passé si badblocks avait été utilisé
conjointement à mkfs.ext2, 3 ou 4; mais je doute qu'un one shot
déclenche les mécanismes de swap des secteurs défectueux, si tant
est qu'il y ait de tels secteurs.

--
<Romain> : J'kiff trop mon frère
<Romain> : Mes parents lui ont parlé de la petite souris vu
qu'il a perdu une dent de lait
<Romain> : Il a "fabriqué" des piege a souris pour la buter
et lui voler toute sa thune...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #25152262
Salut,

Bzzz a écrit :
On Sun, 13 Jan 2013 10:49:42 -0500
Louis-Philippe Gauthier
J'ai fait un badlocks en root



Comme indiqué dans le man, badblocks n'est pas fait pour
être utilisé directement.



Si. Mais sur un disque brut, pas sur un système de fichiers.

# badblocks -v /dev/sdc
Vérification des blocs 0 à 976762582
Vérification des blocs défectueux (test en mode lecture seule) :
complété
Passe complétée, 5 blocs défectueux repérés.



5 blocs sur... 976 millions, ça reste correct.



Non, ce n'est pas correct car les données qu'on a eu le malheur d'écrire
dans ces secteurs sont perdues. Ce qui serait correct, c'est que les
secteurs défectueux aient été automatiquement réalloués par le
contrôleur du disque avant de devenir illisibles.

Si le système de fichier est de type ext2/3/4, il peut être intéressant
de déterminer à quels fichiers ces blocs appartiennent avec debugfs
(commande icheck pour trouver les inodes contenant ces blocs puis ncheck
pour trouver les chemins correspondants à ces inodes).

Il y a moyen d'exécuter smartctl -A sur ce disque ? Ça ne marche pas
toujours sur les disques USB.

Refaire le test en mode écriture non-destructif (des données ;-) ?



Quel intérêt? À moins que le HD n'ait déjà un certain âge.



L'intérêt de l'écriture est de pousser la réallocation des secteurs
défectueux. Mais je ne sais pas si le mode non destructif écrit
justement dans les secteurs illisibles - il n'a pas réussi à lire le
contenu, que va-t-il y écrire ?

Les blocs défectueux sont indexés et ne seront pas utilisé ?



Ça, c'est ce que se serait passé si badblocks avait été utilisé
conjointement à mkfs.ext2, 3 ou 4;



Si le disque est partitionné, ce n'est pas utilisable directement mais
seulement sur une partition contenant un système de fichiers du type
concerné, donc, avec l'option -c de mkfs ou fsck. Si c'est une partition
de swap, mkswap a bien une option -c mais il n'est pas clair si elle ne
fait que vérifier ou si elle met en quarantaine les blocs défectueux
détectés.

mais je doute qu'un one shot
déclenche les mécanismes de swap des secteurs défectueux, si tant
est qu'il y ait de tels secteurs.



Pour forcer la réallocation des secteurs défectueux par le contrôleur
intégré du disque, il faut les détecter (donc essayer de les lire) puis
les écrire. badblocs -w (écriture destructive) le fait, mais cela écrase
tout le contenu, à moins d'utiliser les bornes de début et fin à partir
de la liste des blocs défectueux affichés par l'analyse en lecture seule
(faut pas se louper et écraser les données du bloc d'à côté).

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz
Le #25152372
On Sat, 19 Jan 2013 12:03:45 +0100
Pascal Hambourg
> 5 blocs sur... 976 millions, ça reste correct.

Non, ce n'est pas correct car les données qu'on a eu le malheur d' écrire
dans ces secteurs sont perdues. Ce qui serait correct, c'est que les
secteurs défectueux aient été automatiquement réallou és par le
contrôleur du disque avant de devenir illisibles.



Là-dessus, je ne connais pas le fonctionnement intime du HD,
est-ce sa propre logique qui réalloue (et si oui, comment,
sur erreurs ed lecture, d'écriture?) ou si la logique en
question ne contient que des routines destinées à être
appelées par un pgm externe.


>> Refaire le test en mode écriture non-destructif (des données ;-) ?
>
> Quel intérêt? À moins que le HD n'ait déjà un certain âge.

L'intérêt de l'écriture est de pousser la réallocatio n des secteurs
défectueux.



J'entends bien, mais c'est rarement utile si le HD est "jeune".

Mais je ne sais pas si le mode non destructif écrit
justement dans les secteurs illisibles - il n'a pas réussi à li re le
contenu, que va-t-il y écrire ?



En théorie, tant qu'il n'y a pas eu réallocation et/ou marquage
dans la table des secteurs défectueux, il ne tentera d'écrire
que s'il a lu sans erreur. Reste à savoir ce qui se passe en cas
d'erreur: est-ce que le secteur est réalloué/mis en quarantaine?
(j'en doute) ou bien est-ce que juste un averto est émis?

concerné, donc, avec l'option -c de mkfs ou fsck. Si c'est une parti tion
de swap, mkswap a bien une option -c mais il n'est pas clair si elle ne
fait que vérifier ou si elle met en quarantaine les blocs défec tueux
détectés.



Apparemment non, le temps de formatage entre mkswap -c et mke2fs -c
étant sensiblement différent.
Par contre, ce que j'aimerais bien savoir, c'est si à la suite d'un
mke2fs -c -c on exécute un mkswap, les éventuels secteurs dé fectueux
sont réintégrés comme valides ou non par le mkswap.


Pour forcer la réallocation des secteurs défectueux par le cont rôleur
intégré du disque, il faut les détecter (donc essayer de l es lire) puis
les écrire. badblocs -w (écriture destructive) le fait, mais ce la écrase
tout le contenu, à moins d'utiliser les bornes de début et fin à partir
de la liste des blocs défectueux affichés par l'analyse en lect ure seule
(faut pas se louper et écraser les données du bloc d'à c ôté).



'-n' me parait plus approprié, puisqu'il effectue le même test ma is sans
écraser les données.

--
Axel : Ça sert trop a rien de faire des albums pour Haiti...
Axel : Ils ont plus rien pour les écouter de toute façon.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Frédéric MASSOT
Le #25152502
Le 19/01/2013 12:47, Bzzz a écrit :
On Sat, 19 Jan 2013 12:03:45 +0100
Pascal Hambourg
5 blocs sur... 976 millions, ça reste correct.



Non, ce n'est pas correct car les données qu'on a eu le malheur d'écrire
dans ces secteurs sont perdues. Ce qui serait correct, c'est que les
secteurs défectueux aient été automatiquement réalloués par le
contrôleur du disque avant de devenir illisibles.



Là-dessus, je ne connais pas le fonctionnement intime du HD,
est-ce sa propre logique qui réalloue (et si oui, comment,
sur erreurs ed lecture, d'écriture?) ou si la logique en
question ne contient que des routines destinées à être
appelées par un pgm externe.


Refaire le test en mode écriture non-destructif (des données ;-) ?



Quel intérêt? À moins que le HD n'ait déjà un certain âge.



L'intérêt de l'écriture est de pousser la réallocation des secteurs
défectueux.



J'entends bien, mais c'est rarement utile si le HD est "jeune".



La plupart des disques neufs ont des secteurs défectueux, il est
préférable de faire un test en lecture / écriture (destructif) avant de
l'utiliser et que ces secteurs soient découverts avant la mise en
production.

Lorsque je reçois des disques, je créer une partition sur l'ensemble du
disque et je fais tourner pendant une journée un script comme :

while (true) do
mkfs.ext2 -ccv /dev/sda1;
done;

Ensuite, je le partionne et le format pour son usage.





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #25152782
Frédéric MASSOT a écrit :

La plupart des disques neufs ont des secteurs défectueux,



Sources ?
Il est AMA totalement anormal qu'un disque neuf montre des secteurs
défectueux.

il est
préférable de faire un test en lecture / écriture (destructif) avant de
l'utiliser et que ces secteurs soient découverts avant la mise en
production.



D'accord. Et s'il y en a, retour en garantie.

Lorsque je reçois des disques, je créer une partition sur l'ensemble du
disque et je fais tourner pendant une journée un script comme :

while (true) do
mkfs.ext2 -ccv /dev/sda1;
done;



Ça ne teste que les blocs appartenant à la partition, qui ne couvre pas
tout le disque.
Je ne vois pas trop l'intérêt de mkfs par rapport à une simple
vérification destructive sur tout le disque avec

badblocks -w -p <passes> /dev/sda

où <passes> est le nombre de passes à effectuer.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #25152772
Bzzz a écrit :
Pascal Hambourg
Ce qui serait correct, c'est que les
secteurs défectueux aient été automatiquement réalloués par le
contrôleur du disque avant de devenir illisibles.



Là-dessus, je ne connais pas le fonctionnement intime du HD,
est-ce sa propre logique qui réalloue



Oui.

(et si oui, comment, sur erreurs ed lecture, d'écriture?)



Les deux. En lecture, il y a deux cas :
- le secteur a pu être lu correctement malgré des erreurs (après
plusieurs tentatives par exemple), alors il est réalloué et son contenu
transféré, il n'y a pas de perte de données donc c'est transparent pour
le système hôte ;
- le secteur n'a pas pu être lu, alors il est marqué pour être réalloué
à la prochaine écriture, mais entendant le secteur est illisible et son
contenu est perdu, avec une erreur de lecture remontée au système hôte.

L'idéal, c'est de rester dans le premier cas. On peut le voir avec
l'augmentation des attributs SMART "reallocated", mais les attributs
"pending" restent à zéro.

Refaire le test en mode écriture non-destructif (des données ;-) ?


Quel intérêt? À moins que le HD n'ait déjà un certain âge.


L'intérêt de l'écriture est de pousser la réallocation des secteurs
défectueux.



J'entends bien, mais c'est rarement utile si le HD est "jeune".



Je ne vois pas en quoi l'âge du disque entre en ligne de compte. Un
disque peut avoir des secteurs défectueux à tout âge, ce n'est pas un
signe de vieillissement normal mais un défaut. Pour moi la seule
influence de l'âge c'est si le disque est encore sous garantie et dans
ce cas il faut la faire jouer.

[badblocks]
Mais je ne sais pas si le mode non destructif écrit
justement dans les secteurs illisibles - il n'a pas réussi à lire le
contenu, que va-t-il y écrire ?



En théorie, tant qu'il n'y a pas eu réallocation et/ou marquage
dans la table des secteurs défectueux, il ne tentera d'écrire
que s'il a lu sans erreur.



C'est indiqué où ? Je n'ai rien vu dans la page de manuel de badblocks.

Reste à savoir ce qui se passe en cas
d'erreur: est-ce que le secteur est réalloué/mis en quarantaine?
(j'en doute) ou bien est-ce que juste un averto est émis?



Badblocks ne s'occupe pas de réallocation (c'est le boulot du disque) ni
de mise en quarantaine (c'est le boulot des outils du système de
fichiers comme mkfs ou e2fsck). Il ne fait qu'écrire, lire et signaler
les erreurs.

concerné, donc, avec l'option -c de mkfs ou fsck. Si c'est une partition
de swap, mkswap a bien une option -c mais il n'est pas clair si elle ne
fait que vérifier ou si elle met en quarantaine les blocs défectueux
détectés.



Apparemment non, le temps de formatage entre mkswap -c et mke2fs -c
étant sensiblement différent.



De quel ordre ? Surt un volume de taille conséquente je m'attendrais à
ce que la phase la plus longue soit celle de la vérification, donc dure
le même temps pour les deux commandes. Et cela ne dit rien sur une
éventuelle mise en quarantaine, ce n'est pas ça qui prend du temps.

Par contre, ce que j'aimerais bien savoir, c'est si à la suite d'un
mke2fs -c -c on exécute un mkswap, les éventuels secteurs défectueux
sont réintégrés comme valides ou non par le mkswap.



Là, il faut bien être précis et savoir de quoi on parle.
Les secteurs réalloués par le disque lors du mkfs -cc seront à nouveau
lisibles donc mkswap ne les verra pas comme défectueux. Par contre la
liste des secteurs détectés comme illisibles par mkfs ou fsck fait
partie des méta-données du système de fichiers, qui sont bien sûr
écrasées et ignorées par mkswap.

Pour forcer la réallocation des secteurs défectueux par le contrôleur
intégré du disque, il faut les détecter (donc essayer de les lire) puis
les écrire. badblocs -w (écriture destructive) le fait, mais cela écrase
tout le contenu, à moins d'utiliser les bornes de début et fin à partir
de la liste des blocs défectueux affichés par l'analyse en lecture seule
(faut pas se louper et écraser les données du bloc d'à côté).



'-n' me parait plus approprié, puisqu'il effectue le même test mais sans
écraser les données.



A condition que badblocks -n écrive bien dans les secteurs qu'il n'a pas
pu lire au préalable, ce dont je n'ai pas la certitude. Il se pourrait
qu'il signale le bloc défectueux dès l'échec de la lecture préalable et
saute l'opération d'écriture/vérification.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
J
Le #25155802
Le samedi 19 janvier 2013 à 14:22 +0100, Pascal Hambourg a écrit :
Frédéric MASSOT a écrit :
>
> La plupart des disques neufs ont des secteurs défectueux,

Sources ?
Il est AMA totalement anormal qu'un disque neuf montre des secteurs
défectueux.



Je n'ai pas suivi depuis très très longtemps cette question, mais à
priori c'est au contraire totalement normal dans la mesure ou une
magnétisation est rarement totalement parfaite sur toute la surface.
La gestion de ces secteurs est un moyen pragmatique d'optimiser les
techniques/coûts/qualité de production et augmenter la fiabilité pour un
impact minime en terme de perte de volume de stockage.
S'il en plus qu'un très petit pourcentage de secteurs défectueux, ce
n'est plus un défaut de magnétisation local, mais un défaut de surface
ou de mécanique donc l'appareil doit de toute manière être éliminé.
En tout cas c'était le cas à une époque.

Par contre il me semble que les contrôleurs modernes gèrent en interne
ces secteurs, a vérifier. Donc ce je ne sais pas si c'est forcément
visible du système, ce qui pourrait donner une image "0 secteurs
défectueux". Ça doit être vérifiable avec plusieurs disques neufs de la
même série, en comparant la capacité exacte en octet.

Dans le même genre, toujours à vérifier, il me semble que les
contrôleurs gèrent l'allocation de l'espace pour des raisons
d'optimisation/compression/cache ce qui donnerait une image virtuelle du
disque au système qui pourrait différer quelque peu de son image
physique. En tout cas il en était question à l'époque de mes souvenirs.

Je pense que ça serait intéressant de voir chez Seagate, voire de leur
poser la question sur cette gestion de secteurs si la doc n'est pas
accessible. Ou peut-être que Google a publié quelque chose autour de ce
sujet ? Ils on un bon recul sur la question des disques ^_^;


> il est
> préférable de faire un test en lecture / écriture (destructif) avant
de
> l'utiliser et que ces secteurs soient découverts avant la mise en
> production.



Pour les raisons sus-cité, il me semble que ce qui était indispensable
autrefois est probablement moins vrai aujourd'hui. Par contre, le chic
de ce genre d'appareil électronique étant de tomber en panne dans les
premières heures ou longtemps après, faire ce genre de test doit
probablement faire office de "rodage" et éliminer un risque de défaut de
fabrication (qui pourrait aussi être par exemple un défaut de mémoire,
vu la sophistication des contrôleurs).


D'accord. Et s'il y en a, retour en garantie.


Lire les conditions de garanties avant...

> Lorsque je reçois des disques, je créer une partition sur l'ensemble
du
> disque et je fais tourner pendant une journée un script comme :
>
> while (true) do
> mkfs.ext2 -ccv /dev/sda1;
> done;



Il y a aussi des tests spécifiques pour disques, qui me paraissent
beaucoup plus performants avec des phases aléatoires non-séquentielles.
Si on veut faire de vrai tests, mieux vaut certainement mieux secouer un
peu le disque et non le faire travailler dans des conditions
"optimales".



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #25156022
Jérôme a écrit :
Le samedi 19 janvier 2013 à 14:22 +0100, Pascal Hambourg a écrit :
Il est AMA totalement anormal qu'un disque neuf montre des secteurs
défectueux.



Je n'ai pas suivi depuis très très longtemps cette question, mais à
priori c'est au contraire totalement normal dans la mesure ou une
magnétisation est rarement totalement parfaite sur toute la surface.



Je n'ai pas dû être assez clair : en écrivant "montre", je voulais
parler de secteur défectueux visibles par le système hôte, dont la
lecture ou l'écriture provoque une erreur.

Par contre il me semble que les contrôleurs modernes gèrent en interne
ces secteurs, a vérifier.



Normalement oui, avec les techniques de réallocation. C'est pourquoi ils
ne devraient pas être visibles par le système hôte.

Donc ce je ne sais pas si c'est forcément
visible du système, ce qui pourrait donner une image "0 secteurs
défectueux". Ça doit être vérifiable avec plusieurs disques neufs de la
même série, en comparant la capacité exacte en octet.



La capacité des disques d'un même modèle est la même. C'est du commerce
donc c'est contractuel.

Dans le même genre, toujours à vérifier, il me semble que les
contrôleurs gèrent l'allocation de l'espace pour des raisons
d'optimisation/compression/cache ce qui donnerait une image virtuelle du
disque au système qui pourrait différer quelque peu de son image
physique. En tout cas il en était question à l'époque de mes souvenirs.



Il y a belle lurette que la géométrie cylindres/têtes/secteurs présentée
par le contrôleur intégré est virtuelle et n'a strictement rien à voir
avec la géométrie physique réelle qui est cachée, et qui varie selon les
zones du disque. De toute façon cela n'a plus aucune importance avec
l'adressage linéaire (LBA) où on manipule simplement des numéros de
secteurs de 0 à N-1.

il est
préférable de faire un test en lecture / écriture (destructif) avant


de
l'utiliser et que ces secteurs soient découverts avant la mise en
production.





Pour les raisons sus-cité, il me semble que ce qui était indispensable
autrefois est probablement moins vrai aujourd'hui. Par contre, le chic
de ce genre d'appareil électronique étant de tomber en panne dans les
premières heures ou longtemps après, faire ce genre de test doit
probablement faire office de "rodage" et éliminer un risque de défaut de
fabrication (qui pourrait aussi être par exemple un défaut de mémoire,
vu la sophistication des contrôleurs).



En effet. Fait sur un disque de retour de SAV (visiblement réparé et pas
remplacé par un neuf) , celui-ci a cassé après quelques minutes de ce test.

Il y a aussi des tests spécifiques pour disques, qui me paraissent
beaucoup plus performants avec des phases aléatoires non-séquentielles.
Si on veut faire de vrai tests, mieux vaut certainement mieux secouer un
peu le disque et non le faire travailler dans des conditions
"optimales".



Cela ne teste pas la même chose. Dans un cas on vérifie la surface, dans
l'autre on vérifie la solidité du bras de têtes.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz
Le #25156032
On Sun, 20 Jan 2013 11:50:13 +0100
Jérôme

Je n'ai pas suivi depuis très très longtemps cette question, ma is à
priori c'est au contraire totalement normal dans la mesure ou une
magnétisation est rarement totalement parfaite sur toute la surface.



Non, c'est Pascal qui raison: le test de surface fait partie
de la sortie de ligne de fab.

Et c'est logique pour 2 raisons:

* à quel %age le fabricant pourrait-il déterminer le nb de
secteurs hs à la sortie? question facile à répondre si
c'était le cas: un max.

* les utilisateurs, majoritaires, de w$ se retrouveraient
_tous_ rapidement devant une catastrophe, le formatage
de base étant de type 'rapide'.

C'est aussi la raison pour laquelle les prix ne peuvent
descendre en-dessous d'une certaine barre.

--
Sniper'z: Ca doit être nul d'écrire un roman d'épouvante
Sniper'z: Au début t'as peur de la page blanche
Sniper'z: Après t'as peur de la page remplie

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Louis-Philippe Gauthier
Le #25157852
--bcaec54d46bcbb2de804d3bfabb8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,

Est-ce qu'un ordinateur peut envoyer les données trop rapidement au disqu e
dur USB ? Il est en ext3 et il semble y avoir un problème de mise à jou r du
journal ... Je fais des tests de backups avec Bacula sur ce disque...
peut-il y avoir des configurations particulières (tuning) pour "réduire " le
débit ?


Merci,


Le 20 janvier 2013 07:48, Bzzz
On Sun, 20 Jan 2013 11:50:13 +0100
Jérôme
>
> Je n'ai pas suivi depuis très très longtemps cette question, mais à
> priori c'est au contraire totalement normal dans la mesure ou une
> magnétisation est rarement totalement parfaite sur toute la surface.

Non, c'est Pascal qui raison: le test de surface fait partie
de la sortie de ligne de fab.

Et c'est logique pour 2 raisons:

* à quel %age le fabricant pourrait-il déterminer le nb de
secteurs hs à la sortie? question facile à répondre si
c'était le cas: un max.

* les utilisateurs, majoritaires, de w$ se retrouveraient
_tous_ rapidement devant une catastrophe, le formatage
de base étant de type 'rapide'.

C'est aussi la raison pour laquelle les prix ne peuvent
descendre en-dessous d'une certaine barre.

--
Sniper'z: Ca doit être nul d'écrire un roman d'épouvante
Sniper'z: Au début t'as peur de la page blanche
Sniper'z: Après t'as peur de la page remplie

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/






--
Louis-Philippe Gauthier

--bcaec54d46bcbb2de804d3bfabb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour, <div class="im">On Sun, 20 Jan 2013 11:50:13 +0100<br>
Jérôme &lt; <br>
&gt;<br>
&gt; Je n&#39;ai pas suivi depuis très très longtemps cette question, m ais à<br>
&gt; priori c&#39;est au contraire totalement normal dans la mesure ou une< br>
&gt; magnétisation est rarement totalement parfaite sur toute la surface. <br>
<br>
</div>Non, c&#39;est Pascal qui raison: le test de surface fait partie<br>
de la sortie de ligne de fab.<br>
<br>
Et c&#39;est logique pour 2 raisons:<br>
<br>
* à quel %age le fabricant pourrait-il déterminer le nb de<br>
  secteurs hs à la sortie? question facile à répondre si<br>
  c&#39;était le cas: un max.<br>
<br>
* les utilisateurs, majoritaires, de w$ se retrouveraient<br>
  _tous_ rapidement devant une catastrophe, le formatage<br>
  de base étant de type &#39;rapide&#39;.<br>
<br>
C&#39;est aussi la raison pour laquelle les prix ne peuvent<br>
descendre en-dessous d&#39;une certaine barre.<br>
<br>
--<br>
Sniper&#39;z: Ca doit être nul d&#39;écrire un roman d&#39;épouvante< br>
Sniper&#39;z: Au début t&#39;as peur de la page blanche<br>
Sniper&#39;z: Après t&#39;as peur de la page remplie<br>
<div class="im"><br>
--<br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet &quot;unsubscribe &quot;<br>
vers En cas de soucis, contactez EN ANGLAIS <br>
</blockquote></div><br><br clear="all"><br>-- <br>Louis-Philippe Gauthier <br>

--bcaec54d46bcbb2de804d3bfabb8--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme