j'ai une machine dont le disque déconne (je touche du bois ça fait un
petit moment qu'il n'a pas merdé : linux le remonte en RO suite à erreur)
Voici la sortie de sudo smartctl /dev/sda -d ata -a>log.smart
(scp ~/log.smart .)
https://pastebin.com/U2ExrRcN
Si quelqu'un peut me dire ce qu'il en est (et ce que je peux faire) ça
serait sympa. Changer de disque n'est pas une option, si c'est la seule
solution, j'attends qu'il meure pour de bon et je recycle la machine
--
Le plus grand amour est l'amour d'une mère, vient ensuite l'amour d'un
chien, puis l'amour d'un amant.
-+- Proverbe polonais -+-
Le Sun, 14 Jul 2019 22:49:06 +0200, Pascal Hambourg a écrit :
Et il y a actuellement 7 secteurs illisibles détectés aussi bien lors de commandes que lors d'auto-tests :
Où sont-ils identifiés et comment puis-je les faire connaître au SGF (ext4) ?
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ? Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Le 14/07/2019 à 23:34, Pascal Hambourg a écrit :
Le 14/07/2019 à 23:24, Jo Engo a écrit :
Le Sun, 14 Jul 2019 22:49:06 +0200, Pascal Hambourg a écrit :
Et il y a actuellement 7 secteurs illisibles détectés aussi bien lors de
commandes que lors d'auto-tests :
Où sont-ils identifiés et comment puis-je les faire connaître
au SGF (ext4) ?
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec
l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks :
Si un fichier occupe un de ces secteurs, que peut faire badblocks à part
entériner la perte de l'information qui y est stockée ?
Si ces secteurs sont libres, le contrôleur du disque va probablement les
réallouer à la prochaine écriture dessus.
Le Sun, 14 Jul 2019 22:49:06 +0200, Pascal Hambourg a écrit :
Et il y a actuellement 7 secteurs illisibles détectés aussi bien lors de commandes que lors d'auto-tests :
Où sont-ils identifiés et comment puis-je les faire connaître au SGF (ext4) ?
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ? Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Pascal Hambourg
Le 15/07/2019 à 00:14, Jo Engo a écrit :
Le Sun, 14 Jul 2019 23:58:42 +0200, Pascal Hambourg a écrit :
Je suppose qu'il faut que le système de fichiers soit démonté ou au mieux monté en lecture seule.
C'est une très bonne idée… je croyais qu'en single le système de fichier était en lecture seule or il n'en est rien.
Ça dépend peut-être des distributions. Pas dans Debian en tout cas.
Comment je fais pour le remonter en read only ?
mount -o remount,ro <point de montage|périphérique> mais pas sûr que ça fonctionne si des fichiers sont ouverts en écriture. Sinon, démarrer en passant "ro init=/bin/bash" à la ligne de commande du noyau.
Le 15/07/2019 à 00:14, Jo Engo a écrit :
Le Sun, 14 Jul 2019 23:58:42 +0200, Pascal Hambourg a écrit :
Je suppose qu'il faut que le système de fichiers soit démonté ou au
mieux monté en lecture seule.
C'est une très bonne idée… je croyais qu'en single le système de fichier
était en lecture seule or il n'en est rien.
Ça dépend peut-être des distributions. Pas dans Debian en tout cas.
Comment je fais pour le remonter en read only ?
mount -o remount,ro <point de montage|périphérique>
mais pas sûr que ça fonctionne si des fichiers sont ouverts en écriture.
Sinon, démarrer en passant "ro init=/bin/bash" à la ligne de commande du
noyau.
Le Sun, 14 Jul 2019 23:58:42 +0200, Pascal Hambourg a écrit :
Je suppose qu'il faut que le système de fichiers soit démonté ou au mieux monté en lecture seule.
C'est une très bonne idée… je croyais qu'en single le système de fichier était en lecture seule or il n'en est rien.
Ça dépend peut-être des distributions. Pas dans Debian en tout cas.
Comment je fais pour le remonter en read only ?
mount -o remount,ro <point de montage|périphérique> mais pas sûr que ça fonctionne si des fichiers sont ouverts en écriture. Sinon, démarrer en passant "ro init=/bin/bash" à la ligne de commande du noyau.
Pascal Hambourg
Le 15/07/2019 à 07:12, pehache a écrit :
Le 14/07/2019 à 23:34, Pascal Hambourg a écrit :
Le 14/07/2019 à 23:24, Jo Engo a écrit :
Le Sun, 14 Jul 2019 22:49:06 +0200, Pascal Hambourg a écrit :
Et il y a actuellement 7 secteurs illisibles détectés aussi bien lors de commandes que lors d'auto-tests :
Où sont-ils identifiés et comment puis-je les faire connaître au SGF (ext4) ?
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ?
badblocks ne s'occupe pas des fichiers. C'est le boulot d'e2fsck. De mémoire, les blocs signalés vont être affectés à un inode réservé, ce qui va causer une double affectation, qui va être résolus soit en supprimant les fichiers concernés, soit en leur allouant de nouveaux blocs libres à la place (mais leur contenu sera corrompu de toute façon).
Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Ça, c'est la théorie. En pratique, d'après mon expérience, c'est loin d'être systématique.
Le 15/07/2019 à 07:12, pehache a écrit :
Le 14/07/2019 à 23:34, Pascal Hambourg a écrit :
Le 14/07/2019 à 23:24, Jo Engo a écrit :
Le Sun, 14 Jul 2019 22:49:06 +0200, Pascal Hambourg a écrit :
Et il y a actuellement 7 secteurs illisibles détectés aussi bien
lors de commandes que lors d'auto-tests :
Où sont-ils identifiés et comment puis-je les faire connaître
au SGF (ext4) ?
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec
l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks :
Si un fichier occupe un de ces secteurs, que peut faire badblocks à part
entériner la perte de l'information qui y est stockée ?
badblocks ne s'occupe pas des fichiers. C'est le boulot d'e2fsck.
De mémoire, les blocs signalés vont être affectés à un inode réservé, ce
qui va causer une double affectation, qui va être résolus soit en
supprimant les fichiers concernés, soit en leur allouant de nouveaux
blocs libres à la place (mais leur contenu sera corrompu de toute façon).
Si ces secteurs sont libres, le contrôleur du disque va probablement les
réallouer à la prochaine écriture dessus.
Ça, c'est la théorie. En pratique, d'après mon expérience, c'est loin
d'être systématique.
Le Sun, 14 Jul 2019 22:49:06 +0200, Pascal Hambourg a écrit :
Et il y a actuellement 7 secteurs illisibles détectés aussi bien lors de commandes que lors d'auto-tests :
Où sont-ils identifiés et comment puis-je les faire connaître au SGF (ext4) ?
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ?
badblocks ne s'occupe pas des fichiers. C'est le boulot d'e2fsck. De mémoire, les blocs signalés vont être affectés à un inode réservé, ce qui va causer une double affectation, qui va être résolus soit en supprimant les fichiers concernés, soit en leur allouant de nouveaux blocs libres à la place (mais leur contenu sera corrompu de toute façon).
Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Ça, c'est la théorie. En pratique, d'après mon expérience, c'est loin d'être systématique.
Sergio
Le 15/07/2019 à 07:12, pehache a écrit :
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ?
Entériner la perte de l'information...
Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Le contrôleur de disque ne réalloue pas les secteurs défectueux : Il alloue à la place des secteurs "de réserve" en essayant de relire le secteur défectueux. C'est totalement transparent à l'OS (à part le temps d'accès aux secteurs réalloués) et on ne peut s'en rendre compte que dans les infos SMART. -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 15/07/2019 à 07:12, pehache a écrit :
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks :
Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ?
Entériner la perte de l'information...
Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Le contrôleur de disque ne réalloue pas les secteurs défectueux : Il alloue à la place des secteurs "de réserve" en essayant de relire le secteur défectueux. C'est totalement transparent à l'OS (à
part le temps d'accès aux secteurs réalloués) et on ne peut s'en rendre compte que dans les infos SMART.
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ?
Entériner la perte de l'information...
Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Le contrôleur de disque ne réalloue pas les secteurs défectueux : Il alloue à la place des secteurs "de réserve" en essayant de relire le secteur défectueux. C'est totalement transparent à l'OS (à part le temps d'accès aux secteurs réalloués) et on ne peut s'en rendre compte que dans les infos SMART. -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
pehache
Le 15/07/2019 à 08:37, Sergio a écrit :
Le 15/07/2019 à 07:12, pehache a écrit :
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ?
Entériner la perte de l'information...
Ce qui est à double tranchant. On n'a plus d'erreur de lecture, mais des fichiers corrompus quand même.
Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Le contrôleur de disque ne réalloue pas les secteurs défectueux : Il alloue à la place des secteurs "de réserve" en essayant de relire le secteur défectueux. C'est totalement transparent à l'OS (à part le temps d'accès aux secteurs réalloués) et on ne peut s'en rendre compte que dans les infos SMART.
Merci d'avoir paraphraser ce que j'ai écrit, mais était-ce bien nécessaire ?
Le 15/07/2019 à 08:37, Sergio a écrit :
Le 15/07/2019 à 07:12, pehache a écrit :
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option
-c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks :
Si un fichier occupe un de ces secteurs, que peut faire badblocks à part
entériner la perte de l'information qui y est stockée ?
Entériner la perte de l'information...
Ce qui est à double tranchant. On n'a plus d'erreur de lecture, mais des
fichiers corrompus quand même.
Si ces secteurs sont libres, le contrôleur du disque va probablement les
réallouer à la prochaine écriture dessus.
Le contrôleur de disque ne réalloue pas les secteurs défectueux : Il alloue
à la place des secteurs "de réserve" en essayant de relire le secteur
défectueux. C'est totalement transparent à l'OS (à
part le temps d'accès aux secteurs réalloués) et on ne peut s'en rendre
compte que dans les infos SMART.
Merci d'avoir paraphraser ce que j'ai écrit, mais était-ce bien
nécessaire ?
Le moyen le plus simple et le plus sûr, c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
Il y a un truc que je ne comprends pas avec badblocks : Si un fichier occupe un de ces secteurs, que peut faire badblocks à part entériner la perte de l'information qui y est stockée ?
Entériner la perte de l'information...
Ce qui est à double tranchant. On n'a plus d'erreur de lecture, mais des fichiers corrompus quand même.
Si ces secteurs sont libres, le contrôleur du disque va probablement les réallouer à la prochaine écriture dessus.
Le contrôleur de disque ne réalloue pas les secteurs défectueux : Il alloue à la place des secteurs "de réserve" en essayant de relire le secteur défectueux. C'est totalement transparent à l'OS (à part le temps d'accès aux secteurs réalloués) et on ne peut s'en rendre compte que dans les infos SMART.
Merci d'avoir paraphraser ce que j'ai écrit, mais était-ce bien nécessaire ?
Jo Engo
Le Mon, 15 Jul 2019 07:23:52 +0200, Pascal Hambourg a écrit :
Comment je fais pour le remonter en read only ?
mount -o remount,ro <point de montage|périphérique> mais pas sûr que ça fonctionne si des fichiers sont ouverts en écriture. Sinon, démarrer en passant "ro init=/bin/bash" à la ligne de commande du noyau.
<Ctrl><Alt><Syst>r+<Ctrl><Alt><Syst>u a très bien marché (j'aurais peut- être dû faire un <Ctrl><Alt><Syst>u avant bon maintenant c'est trop tard). J'aurais dû y penser avant… -- Le peuple français est incapable d'un régicide. -+- Louis XVI, 1789 -+-
Le Mon, 15 Jul 2019 07:23:52 +0200, Pascal Hambourg a écrit :
Comment je fais pour le remonter en read only ?
mount -o remount,ro <point de montage|périphérique>
mais pas sûr que ça fonctionne si des fichiers sont ouverts en écriture.
Sinon, démarrer en passant "ro init=/bin/bash" à la ligne de commande du
noyau.
<Ctrl><Alt><Syst>r+<Ctrl><Alt><Syst>u a très bien marché (j'aurais peut-
être dû faire un <Ctrl><Alt><Syst>u avant bon maintenant c'est trop
tard). J'aurais dû y penser avant…
--
Le peuple français est incapable d'un régicide.
-+- Louis XVI, 1789 -+-
Le Mon, 15 Jul 2019 07:23:52 +0200, Pascal Hambourg a écrit :
Comment je fais pour le remonter en read only ?
mount -o remount,ro <point de montage|périphérique> mais pas sûr que ça fonctionne si des fichiers sont ouverts en écriture. Sinon, démarrer en passant "ro init=/bin/bash" à la ligne de commande du noyau.
<Ctrl><Alt><Syst>r+<Ctrl><Alt><Syst>u a très bien marché (j'aurais peut- être dû faire un <Ctrl><Alt><Syst>u avant bon maintenant c'est trop tard). J'aurais dû y penser avant… -- Le peuple français est incapable d'un régicide. -+- Louis XVI, 1789 -+-
Jo Engo
Le Sun, 14 Jul 2019 23:40:39 +0200, Pascal Hambourg a écrit :
c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
0.75 → 3'13 règle de 3 3'133s 1% → 144.75s 100% → 14475 s=4h et des brouettes, dommage que je n'ai pas pensé hier soir à faire <Ctrl><Alt><Syst>u… -- JOUISSIF P : Et dire que tous les ans, des centaines d'enfants exploités au tiers monde meurent dans des mines de sable à chat... Aah !... c'est trop bon !
Le Sun, 14 Jul 2019 23:40:39 +0200, Pascal Hambourg a écrit :
c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec
les options qui vont bien.
0.75 → 3'13
règle de 3
3'133s
1% → 144.75s
100% → 14475 s=4h et des brouettes, dommage que je n'ai pas pensé hier
soir à faire <Ctrl><Alt><Syst>u…
--
JOUISSIF
P : Et dire que tous les ans, des centaines d'enfants exploités au tiers
monde meurent dans des mines de sable à chat... Aah !... c'est trop bon !
Le Sun, 14 Jul 2019 23:40:39 +0200, Pascal Hambourg a écrit :
c'est d'exécuter e2fsck avec l'option -c qui appellera badblocks avec les options qui vont bien.
0.75 → 3'13 règle de 3 3'133s 1% → 144.75s 100% → 14475 s=4h et des brouettes, dommage que je n'ai pas pensé hier soir à faire <Ctrl><Alt><Syst>u… -- JOUISSIF P : Et dire que tous les ans, des centaines d'enfants exploités au tiers monde meurent dans des mines de sable à chat... Aah !... c'est trop bon !
Jo Engo
Le Mon, 15 Jul 2019 07:43:06 +0000, Jo Engo a écrit :
Comment je fais pour le remonter en read only ?
<Ctrl><Alt><Syst>r+<Ctrl><Alt><Syst>u a très bien marché (j'aurais peut- être dû faire un <Ctrl><Alt><Syst>u avant
<Ctrl><Alt><Syst>s eut été mieux
bon maintenant c'est trop tard). J'aurais dû y penser avant…
-- Je désire être incinéré et je veux que 10% de mes cendres soient versées a mon impresario. -+- Groucho Marx -+-
Le Mon, 15 Jul 2019 07:43:06 +0000, Jo Engo a écrit :
Comment je fais pour le remonter en read only ?
<Ctrl><Alt><Syst>r+<Ctrl><Alt><Syst>u a très bien marché (j'aurais peut-
être dû faire un <Ctrl><Alt><Syst>u avant
<Ctrl><Alt><Syst>s eut été mieux
bon maintenant c'est trop
tard). J'aurais dû y penser avant…
--
Je désire être incinéré et je veux que 10% de mes cendres soient
versées a mon impresario.
-+- Groucho Marx -+-
Le Mon, 15 Jul 2019 07:43:06 +0000, Jo Engo a écrit :
Comment je fais pour le remonter en read only ?
<Ctrl><Alt><Syst>r+<Ctrl><Alt><Syst>u a très bien marché (j'aurais peut- être dû faire un <Ctrl><Alt><Syst>u avant
<Ctrl><Alt><Syst>s eut été mieux
bon maintenant c'est trop tard). J'aurais dû y penser avant…
-- Je désire être incinéré et je veux que 10% de mes cendres soient versées a mon impresario. -+- Groucho Marx -+-
Lulu
Le 14-07-2019, Pascal Hambourg a écrit :
Le 14/07/2019 à 10:26, Sergio a écrit :
Erreurs lecture/écriture sur le disque -> disque prêt à mourir
Pas forcément. Un disque peut vivre encore très longtemps avec des secteurs défectueux.
Je me trompe peut-être, mais j'avais cru comprendre qu'un disque est vendu avec des "secteurs de secours" qui peuvent être alloués quand les secteurs déjà alloués "mouraient" et que tant que la réserve de "secteurs de secours" n'était pas épuisée, c'était transparent pour l'OS puisque géré par le controleur. Mais c'est ce que j'en avais compris quand je mettais penché sur le sujet, il y a 4 ou 5 ans. Des infos sur la gestion des secteurs défectueux ?
Le 14-07-2019, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 14/07/2019 à 10:26, Sergio a écrit :
> Erreurs lecture/écriture sur le disque -> disque prêt à mourir
Pas forcément. Un disque peut vivre encore très longtemps avec des
secteurs défectueux.
Je me trompe peut-être, mais j'avais cru comprendre qu'un disque est
vendu avec des "secteurs de secours" qui peuvent être alloués quand les
secteurs déjà alloués "mouraient" et que tant que la réserve de
"secteurs de secours" n'était pas épuisée, c'était transparent pour l'OS
puisque géré par le controleur.
Mais c'est ce que j'en avais compris quand je mettais penché sur le
sujet, il y a 4 ou 5 ans.
Des infos sur la gestion des secteurs défectueux ?
Erreurs lecture/écriture sur le disque -> disque prêt à mourir
Pas forcément. Un disque peut vivre encore très longtemps avec des secteurs défectueux.
Je me trompe peut-être, mais j'avais cru comprendre qu'un disque est vendu avec des "secteurs de secours" qui peuvent être alloués quand les secteurs déjà alloués "mouraient" et que tant que la réserve de "secteurs de secours" n'était pas épuisée, c'était transparent pour l'OS puisque géré par le controleur. Mais c'est ce que j'en avais compris quand je mettais penché sur le sujet, il y a 4 ou 5 ans. Des infos sur la gestion des secteurs défectueux ?
Jo Engo
La question mérite d'être posée sur fc.stockage et y trouvera plus de réponses d'autant comme tu le fais remarquer c'est transparent pour l'OS (je dirais même plus, c'est indépendant de celui-ci ): La question de Lulu, ci-dessous Le Mon, 15 Jul 2019 14:22:10 +0200, Lulu a écrit :
Le 14-07-2019, Pascal Hambourg a écrit :
Le 14/07/2019 à 10:26, Sergio a écrit :
Erreurs lecture/écriture sur le disque -> disque prêt à mourir
Pas forcément. Un disque peut vivre encore très longtemps avec des secteurs défectueux.
Je me trompe peut-être, mais j'avais cru comprendre qu'un disque est vendu avec des "secteurs de secours" qui peuvent être alloués quand les secteurs déjà alloués "mouraient" et que tant que la réserve de "secteurs de secours" n'était pas épuisée, c'était transparent pour l'OS puisque géré par le controleur. Mais c'est ce que j'en avais compris quand je mettais penché sur le sujet, il y a 4 ou 5 ans. Des infos sur la gestion des secteurs défectueux ?
-- Ni rame de marin, Ni ta misère si matin, Ni talent né latin, Ni lama malin, Ni mage gamin, Ni âme demain, Ni vide divin, Ni fin. -- Roche, Jean
La question mérite d'être posée sur fc.stockage et y trouvera plus de
réponses d'autant comme tu le fais remarquer c'est transparent pour l'OS
(je dirais même plus, c'est indépendant de celui-ci ):
La question de Lulu, ci-dessous
Le Mon, 15 Jul 2019 14:22:10 +0200, Lulu a écrit :
Le 14-07-2019, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 14/07/2019 à 10:26, Sergio a écrit :
> Erreurs lecture/écriture sur le disque -> disque prêt à mourir
Pas forcément. Un disque peut vivre encore très longtemps avec des
secteurs défectueux.
Je me trompe peut-être, mais j'avais cru comprendre qu'un disque est
vendu avec des "secteurs de secours" qui peuvent être alloués quand les
secteurs déjà alloués "mouraient" et que tant que la réserve de
"secteurs de secours" n'était pas épuisée, c'était transparent pour l'OS
puisque géré par le controleur.
Mais c'est ce que j'en avais compris quand je mettais penché sur le
sujet, il y a 4 ou 5 ans.
Des infos sur la gestion des secteurs défectueux ?
--
Ni rame de marin,
Ni ta misère si matin,
Ni talent né latin,
Ni lama malin,
Ni mage gamin,
Ni âme demain,
Ni vide divin,
Ni fin.
-- Roche, Jean
La question mérite d'être posée sur fc.stockage et y trouvera plus de réponses d'autant comme tu le fais remarquer c'est transparent pour l'OS (je dirais même plus, c'est indépendant de celui-ci ): La question de Lulu, ci-dessous Le Mon, 15 Jul 2019 14:22:10 +0200, Lulu a écrit :
Le 14-07-2019, Pascal Hambourg a écrit :
Le 14/07/2019 à 10:26, Sergio a écrit :
Erreurs lecture/écriture sur le disque -> disque prêt à mourir
Pas forcément. Un disque peut vivre encore très longtemps avec des secteurs défectueux.
Je me trompe peut-être, mais j'avais cru comprendre qu'un disque est vendu avec des "secteurs de secours" qui peuvent être alloués quand les secteurs déjà alloués "mouraient" et que tant que la réserve de "secteurs de secours" n'était pas épuisée, c'était transparent pour l'OS puisque géré par le controleur. Mais c'est ce que j'en avais compris quand je mettais penché sur le sujet, il y a 4 ou 5 ans. Des infos sur la gestion des secteurs défectueux ?
-- Ni rame de marin, Ni ta misère si matin, Ni talent né latin, Ni lama malin, Ni mage gamin, Ni âme demain, Ni vide divin, Ni fin. -- Roche, Jean
