Forum Linux francophone oblige :) , voilà ma question:
J'ai installé un kernel 2.6.5 sur mon ordinateur mais il bloque au boot sur
mon hdb de 80 gig. Il veut que je lui fasse un fsck alors que tout va bien
avec le kernel 2.4.22.
J'ai tenté la manip mais fsck refuse de faire son travail, même en utilisant
toutes les valeurs de blocs disponibles.
Mon disque est partitionné comme suit: hdb2 (79,3 gigs) et une partition de
swap à la fin du disque de 700 megs (peut-être est-ce ça?).
Quelqu'un aurait un indice où une doc pour m'orienter vers la solution?
Je précise que j'ai déjà lu les man de fsck, ext3 et autres, et cherché sur
Gougeule sans résultat.
"Paul Pygeon" a écrit dans le message de news:Avgdc.673$
J'ai installé un kernel 2.6.5 sur mon ordinateur mais il bloque au boot sur
mon hdb de 80 gig. Il veut que je lui fasse un fsck alors que tout va bien avec le kernel 2.4.22.
Vous n'auriez pas par hasard un BIOS trop ancien ne supportant pas les disques de 80 Go, et auriez dans ce cas installé un utilitaire (il en existe de nombreux et ils sont souvent fournis par le fabriquant du disque) permettant quand même d'utiliser tout l'espace disque ?
Dans ce cas ne cherchez pas plus loin, c'est ça... Par contre je n'ai pas de solution à vous proposer.
"Paul Pygeon" <flipper@globetrotter.com> a écrit dans le message de
news:Avgdc.673$AT3.192@charlie.risq.qc.ca...
J'ai installé un kernel 2.6.5 sur mon ordinateur mais il bloque au boot
sur
mon hdb de 80 gig. Il veut que je lui fasse un fsck alors que tout va bien
avec le kernel 2.4.22.
Vous n'auriez pas par hasard un BIOS trop ancien ne supportant pas les
disques de 80 Go, et auriez dans ce cas installé un utilitaire (il en existe
de nombreux et ils sont souvent fournis par le fabriquant du disque)
permettant quand même d'utiliser tout l'espace disque ?
Dans ce cas ne cherchez pas plus loin, c'est ça... Par contre je n'ai pas de
solution à vous proposer.
"Paul Pygeon" a écrit dans le message de news:Avgdc.673$
J'ai installé un kernel 2.6.5 sur mon ordinateur mais il bloque au boot sur
mon hdb de 80 gig. Il veut que je lui fasse un fsck alors que tout va bien avec le kernel 2.4.22.
Vous n'auriez pas par hasard un BIOS trop ancien ne supportant pas les disques de 80 Go, et auriez dans ce cas installé un utilitaire (il en existe de nombreux et ils sont souvent fournis par le fabriquant du disque) permettant quand même d'utiliser tout l'espace disque ?
Dans ce cas ne cherchez pas plus loin, c'est ça... Par contre je n'ai pas de solution à vous proposer.
Paul Pygeon
Le 9 Avril 2004 02:58 Franck a écrit en cette journée dans fr.comp.os.linux.configuration:
Vous n'auriez pas par hasard un BIOS trop ancien ne supportant pas les disques de 80 Go, et auriez dans ce cas installé un utilitaire (il en existe de nombreux et ils sont souvent fournis par le fabriquant du disque) permettant quand même d'utiliser tout l'espace disque ?
Non, de ce côté ça va. La carte est toute neuve, deux mois à peine.
Merci quand même. Malgré tout je sèche encore. Toutes mes recherches sur le sujet n'ont encore rien donné jusqu'à maintenant.
Le 9 Avril 2004 02:58 Franck a écrit en cette journée dans
fr.comp.os.linux.configuration:
Vous n'auriez pas par hasard un BIOS trop ancien ne supportant pas les
disques de 80 Go, et auriez dans ce cas installé un utilitaire (il en
existe de nombreux et ils sont souvent fournis par le fabriquant du
disque) permettant quand même d'utiliser tout l'espace disque ?
Non, de ce côté ça va. La carte est toute neuve, deux mois à peine.
Merci quand même. Malgré tout je sèche encore. Toutes mes recherches sur le
sujet n'ont encore rien donné jusqu'à maintenant.
Le 9 Avril 2004 02:58 Franck a écrit en cette journée dans fr.comp.os.linux.configuration:
Vous n'auriez pas par hasard un BIOS trop ancien ne supportant pas les disques de 80 Go, et auriez dans ce cas installé un utilitaire (il en existe de nombreux et ils sont souvent fournis par le fabriquant du disque) permettant quand même d'utiliser tout l'espace disque ?
Non, de ce côté ça va. La carte est toute neuve, deux mois à peine.
Merci quand même. Malgré tout je sèche encore. Toutes mes recherches sur le sujet n'ont encore rien donné jusqu'à maintenant.
no_spam
On Fri, 09 Apr 2004 01:44:15 +0200, Annie D. wrote:
no_spam wrote:
les disques sont souvent plus rapide au bébut qu'a la fin
C'est une légende, ou plutot, ce n'est plus vrai depuis longtemps,
Ben voyons. Vous, vous n'avez pas dû faire beaucoup de mesures de débit. Le fait est là : le débit d'un disque dur soutenu décroit au fur et à mesure qu'on avance dans les numéros de secteurs et donc qu'on s'éloigne de la périphérie des plateaux.
C'est physiquement vrai, mais il n'y a que sur un disque neuf que c'est vrai au niveau user. Voir plus bas...
puisque les numéros de secteurs ne correspondent pas aux emplacements physiques sur le disque:
Bien sûr que si. Ce sont les paramètres CHS qui n'ont plus aucune réalité physique depuis longtemps. Sauf remappage de secteur défectueux, le secteur n+1 est localisé physiquemement juste après le secteur n.
Et non, ça n'est plus vrai depuis longtemps. Pour des questions de vitesse d'accès, on essaye de faire en sorte que le secteur n+1 ne soit "pas trop loin" du secteur n, mais c'est tout.
le controleur interne remappe
Il remappe les secteurs défectueux. Pourquoi en remapperait-il d'autres ?
Parce que les techniques de stockage actuelles sont très peu fiables et que les données ne sont pas stockées dans le format envoyé par l'OS.
et "optimise" les écritures. C'est un système un peu du même genre que le FTL/NFTL
Qu'est-ce que c'est ?
des flash.
Une mémoire flash est un composant purement électronique. Les temps d'accès n'ont rien à voir avec ceux d'un disque mécanique, on peut se permettre de mapper comme on veut.
Effectivement. Mais, tout comme les disques durs modernes, il y a du remapage de blocs en interne. Dans le cas des flash, le problème est que le nombre d'effacement possible pour chaque bloc est limité. Par contre, il est possible de changer des bits, dans un sens seulement, pour changer le contenu d'un bloc. Donc, la couche FTL/NFTL remappe les blocs en essayant de répartir "l'usure" sur tous les blocs. Pour les disques durs, le problème est autre: le format de stockage physique est différent du format des données envoyées, d'une part, et d'autre part, le taux d'erreur est très élevé. Les données sont donc compressées, et stockées de façon extrèmement redondantes. Comme on ne peut pas savoir à l'avance la taille nécessaire pour stocker un bloc compressé + les données redondantes, le bloc est remappé à l'endroit ou il y a la place de le stocker. IL y a donc deux remapages successifs: une table permet de remapper les zones défectueusees du disque, la seconde permet de connaitre l'emplacement physique du numéro de bloc logique ainsi calculé. D'après IBM (maintenant Hitachi): "The majority of disk drives manufactured today use an addressing scheme where the data sectors are identified to the host system by a logical block number (LBN). In operation, the host computer sends a list of logical block numbers to be written or read. The disk drive converts these values into zone, cylinder, head and sector (ZCHS) values." Les "logical blocs numbers" ne sont clairement pas des emplacements physiques...
On Fri, 09 Apr 2004 01:44:15 +0200, Annie D. wrote:
no_spam wrote:
les disques sont souvent plus rapide au bébut qu'a la fin
C'est une légende, ou plutot, ce n'est plus vrai depuis longtemps,
Ben voyons. Vous, vous n'avez pas dû faire beaucoup de mesures de débit.
Le fait est là : le débit d'un disque dur soutenu décroit au fur et à
mesure qu'on avance dans les numéros de secteurs et donc qu'on s'éloigne
de la périphérie des plateaux.
C'est physiquement vrai, mais il n'y a que sur un disque neuf
que c'est vrai au niveau user. Voir plus bas...
puisque les numéros de secteurs ne correspondent pas aux
emplacements physiques sur le disque:
Bien sûr que si. Ce sont les paramètres CHS qui n'ont plus aucune
réalité physique depuis longtemps. Sauf remappage de secteur défectueux,
le secteur n+1 est localisé physiquemement juste après le secteur n.
Et non, ça n'est plus vrai depuis longtemps.
Pour des questions de vitesse d'accès, on essaye de faire en sorte
que le secteur n+1 ne soit "pas trop loin" du secteur n, mais
c'est tout.
le controleur interne remappe
Il remappe les secteurs défectueux. Pourquoi en remapperait-il d'autres
?
Parce que les techniques de stockage actuelles sont très peu fiables
et que les données ne sont pas stockées dans le format envoyé par
l'OS.
et "optimise" les écritures. C'est un système un peu
du même genre que le FTL/NFTL
Qu'est-ce que c'est ?
des flash.
Une mémoire flash est un composant purement électronique. Les temps
d'accès n'ont rien à voir avec ceux d'un disque mécanique, on peut se
permettre de mapper comme on veut.
Effectivement. Mais, tout comme les disques durs modernes,
il y a du remapage de blocs en interne. Dans le cas des flash,
le problème est que le nombre d'effacement possible pour chaque
bloc est limité. Par contre, il est possible de changer des bits,
dans un sens seulement, pour changer le contenu d'un bloc. Donc, la
couche FTL/NFTL remappe les blocs en essayant de répartir "l'usure" sur
tous les blocs.
Pour les disques durs, le problème est autre: le format de stockage
physique est différent du format des données envoyées, d'une part,
et d'autre part, le taux d'erreur est très élevé. Les données sont
donc compressées, et stockées de façon extrèmement redondantes.
Comme on ne peut pas savoir à l'avance la taille nécessaire pour
stocker un bloc compressé + les données redondantes, le bloc est
remappé à l'endroit ou il y a la place de le stocker.
IL y a donc deux remapages successifs:
une table permet de remapper les zones défectueusees du disque,
la seconde permet de connaitre l'emplacement physique du numéro
de bloc logique ainsi calculé.
D'après IBM (maintenant Hitachi):
"The majority of disk drives manufactured today use an addressing scheme
where the data sectors are identified to the host system by a logical
block number (LBN). In operation, the host computer sends a list of
logical block numbers to be written or read. The disk drive converts these
values into zone, cylinder, head and sector (ZCHS) values."
Les "logical blocs numbers" ne sont clairement pas des emplacements
physiques...
On Fri, 09 Apr 2004 01:44:15 +0200, Annie D. wrote:
no_spam wrote:
les disques sont souvent plus rapide au bébut qu'a la fin
C'est une légende, ou plutot, ce n'est plus vrai depuis longtemps,
Ben voyons. Vous, vous n'avez pas dû faire beaucoup de mesures de débit. Le fait est là : le débit d'un disque dur soutenu décroit au fur et à mesure qu'on avance dans les numéros de secteurs et donc qu'on s'éloigne de la périphérie des plateaux.
C'est physiquement vrai, mais il n'y a que sur un disque neuf que c'est vrai au niveau user. Voir plus bas...
puisque les numéros de secteurs ne correspondent pas aux emplacements physiques sur le disque:
Bien sûr que si. Ce sont les paramètres CHS qui n'ont plus aucune réalité physique depuis longtemps. Sauf remappage de secteur défectueux, le secteur n+1 est localisé physiquemement juste après le secteur n.
Et non, ça n'est plus vrai depuis longtemps. Pour des questions de vitesse d'accès, on essaye de faire en sorte que le secteur n+1 ne soit "pas trop loin" du secteur n, mais c'est tout.
le controleur interne remappe
Il remappe les secteurs défectueux. Pourquoi en remapperait-il d'autres ?
Parce que les techniques de stockage actuelles sont très peu fiables et que les données ne sont pas stockées dans le format envoyé par l'OS.
et "optimise" les écritures. C'est un système un peu du même genre que le FTL/NFTL
Qu'est-ce que c'est ?
des flash.
Une mémoire flash est un composant purement électronique. Les temps d'accès n'ont rien à voir avec ceux d'un disque mécanique, on peut se permettre de mapper comme on veut.
Effectivement. Mais, tout comme les disques durs modernes, il y a du remapage de blocs en interne. Dans le cas des flash, le problème est que le nombre d'effacement possible pour chaque bloc est limité. Par contre, il est possible de changer des bits, dans un sens seulement, pour changer le contenu d'un bloc. Donc, la couche FTL/NFTL remappe les blocs en essayant de répartir "l'usure" sur tous les blocs. Pour les disques durs, le problème est autre: le format de stockage physique est différent du format des données envoyées, d'une part, et d'autre part, le taux d'erreur est très élevé. Les données sont donc compressées, et stockées de façon extrèmement redondantes. Comme on ne peut pas savoir à l'avance la taille nécessaire pour stocker un bloc compressé + les données redondantes, le bloc est remappé à l'endroit ou il y a la place de le stocker. IL y a donc deux remapages successifs: une table permet de remapper les zones défectueusees du disque, la seconde permet de connaitre l'emplacement physique du numéro de bloc logique ainsi calculé. D'après IBM (maintenant Hitachi): "The majority of disk drives manufactured today use an addressing scheme where the data sectors are identified to the host system by a logical block number (LBN). In operation, the host computer sends a list of logical block numbers to be written or read. The disk drive converts these values into zone, cylinder, head and sector (ZCHS) values." Les "logical blocs numbers" ne sont clairement pas des emplacements physiques...
Motodashi
Le Thu, 8 Apr 2004 23:04:33 +0200, Eric PETIT a écrit:
Paul Pygeon wrote:
petite précision entre parenthèse, ce partitionnement me semble tout sauf cohérent, en effet les disques sont souvent plus rapide au bébut qu'a la fin. Tu ferais mieux d'inverser tes deux partitions :o)
Je m'étais laissé dire qu'il fallait laisser le swap en fin de dd.
-- <Mooby> dites comment on fait pour lancer un prg sous NT? on double clique dessus, c'est bien ca ?
- #linuxfr
Le Thu, 8 Apr 2004 23:04:33 +0200, Eric PETIT <nulle@part.fr> a écrit:
Paul Pygeon wrote:
petite précision entre parenthèse, ce partitionnement me semble tout sauf
cohérent, en effet les disques sont souvent plus rapide au bébut qu'a la
fin. Tu ferais mieux d'inverser tes deux partitions :o)
Je m'étais laissé dire qu'il fallait laisser le swap en fin de dd.
--
<Mooby> dites comment on fait pour lancer un prg sous NT? on double
clique dessus, c'est bien ca ?
Le Thu, 8 Apr 2004 23:04:33 +0200, Eric PETIT a écrit:
Paul Pygeon wrote:
petite précision entre parenthèse, ce partitionnement me semble tout sauf cohérent, en effet les disques sont souvent plus rapide au bébut qu'a la fin. Tu ferais mieux d'inverser tes deux partitions :o)
Je m'étais laissé dire qu'il fallait laisser le swap en fin de dd.
-- <Mooby> dites comment on fait pour lancer un prg sous NT? on double clique dessus, c'est bien ca ?
- #linuxfr
Annie D.
no_spam wrote:
Ben voyons. Vous, vous n'avez pas dû faire beaucoup de mesures de débit. Le fait est là : le débit d'un disque dur soutenu décroit au fur et à mesure qu'on avance dans les numéros de secteurs et donc qu'on s'éloigne de la périphérie des plateaux.
C'est physiquement vrai, mais il n'y a que sur un disque neuf que c'est vrai au niveau user. Voir plus bas...
Etonnant, j'ai tout un tas de disques qui sont loin d'être neufs et ils ont tous un profil de décroissance continue ou par paliers du débit en fonction du numéro de secteur. Par ailleurs on peut voir ces même courbes sur les sites de test de matériel comme Hardware.fr.
Faites des mesures, vous dis-je. Les faits sont têtus.
Pour des questions de vitesse d'accès, on essaye de faire en sorte que le secteur n+1 ne soit "pas trop loin" du secteur n, mais c'est tout.
Vous parlez d'entrelacement (interleaving) ? C'est au contraire cette technique utilisée avec les disquettes et les disques ST506 (aussi dénommé MFM/RLL, impoprement) a été abandonnée avec l'intégration du contrôleur dans les disques IDE et SCSI. Depuis le facteur d'entrelacement est de 1 (pas d'entrelacement) car c'est ce qui permet le meilleur débit soutenu : pas besoin de sauter n secteurs physiques pour accéder au secteur logique suivant.
Il [le contrôleur interne] remappe les secteurs défectueux. Pourquoi en remapperait-il d'autres ?
Parce que les techniques de stockage actuelles sont très peu fiables et que les données ne sont pas stockées dans le format envoyé par l'OS.
De quoi parlez-vous ? Des techniques de détection et correction d'erreur (ECC) ? Qu'est-ce que ça a à voir avec la position des secteurs ?
Dans le cas des flash, le problème est que le nombre d'effacement possible pour chaque bloc est limité.
En effet, il y a quelques années c'était de l'ordre de 100000. Mais ça a dû s'améliorer.
Par contre, il est possible de changer des bits, dans un sens seulement, pour changer le contenu d'un bloc.
En effet, l'écriture consiste à mettre à zéro un bit précédemment à un, mais pour revenir à un il faut effacer.
Donc, la couche FTL/NFTL remappe les blocs en essayant de répartir "l'usure" sur tous les blocs.
Compris. Est-ce géré par l'OS ou le contrôleur de mémoire flash ?
Pour les disques durs, le problème est autre: le format de stockage physique est différent du format des données envoyées, d'une part,
Que voulez-vous dire ?
et d'autre part, le taux d'erreur est très élevé.
Bah, les techniques de redondance à base d'ECC ne sont pas faites pour les chiens. La preuve, ça marche plutôt bien.
Les données sont donc compressées
Par le contrôleur intégré ? Jamais entendu parler, auriez-vous une référence ? Ça me paraît hautement improbable : on aurait une capacité variable en fonction des données stockées.
Comme on ne peut pas savoir à l'avance la taille nécessaire pour stocker un bloc compressé + les données redondantes, le bloc est remappé à l'endroit ou il y a la place de le stocker.
Dites, vous ne seriez pas en train de confondre le boulot du contrôleur interne avec les systèmes de fichiers qui utilisent la compression à la volée ?
D'après IBM (maintenant Hitachi): "The majority of disk drives manufactured today use an addressing scheme where the data sectors are identified to the host system by a logical block number (LBN). In operation, the host computer sends a list of logical block numbers to be written or read. The disk drive converts these values into zone, cylinder, head and sector (ZCHS) values." Les "logical blocs numbers" ne sont clairement pas des emplacements physiques...
Maiss il n'est pas dit que les secteurs de numéros LBA consécutifs ne sont pas globalement rangés séquentiellement. S'ils ne l'étaient pas, les efforts des OS et systèmes de fichiers pour limiter la fragmentation seraient vains puisque ceux-ci n'ont aucun moyen de connaître la position réelle des secteurs.
no_spam wrote:
Ben voyons. Vous, vous n'avez pas dû faire beaucoup de mesures de débit.
Le fait est là : le débit d'un disque dur soutenu décroit au fur et à
mesure qu'on avance dans les numéros de secteurs et donc qu'on s'éloigne
de la périphérie des plateaux.
C'est physiquement vrai, mais il n'y a que sur un disque neuf
que c'est vrai au niveau user. Voir plus bas...
Etonnant, j'ai tout un tas de disques qui sont loin d'être neufs et ils
ont tous un profil de décroissance continue ou par paliers du débit en
fonction du numéro de secteur. Par ailleurs on peut voir ces même
courbes sur les sites de test de matériel comme Hardware.fr.
Faites des mesures, vous dis-je. Les faits sont têtus.
Pour des questions de vitesse d'accès, on essaye de faire en sorte
que le secteur n+1 ne soit "pas trop loin" du secteur n, mais
c'est tout.
Vous parlez d'entrelacement (interleaving) ? C'est au contraire cette
technique utilisée avec les disquettes et les disques ST506 (aussi
dénommé MFM/RLL, impoprement) a été abandonnée avec l'intégration du
contrôleur dans les disques IDE et SCSI. Depuis le facteur
d'entrelacement est de 1 (pas d'entrelacement) car c'est ce qui permet
le meilleur débit soutenu : pas besoin de sauter n secteurs physiques
pour accéder au secteur logique suivant.
Il [le contrôleur interne] remappe les secteurs défectueux.
Pourquoi en remapperait-il d'autres ?
Parce que les techniques de stockage actuelles sont très peu fiables
et que les données ne sont pas stockées dans le format envoyé par
l'OS.
De quoi parlez-vous ? Des techniques de détection et correction d'erreur
(ECC) ? Qu'est-ce que ça a à voir avec la position des secteurs ?
Dans le cas des flash, le problème est que le nombre d'effacement
possible pour chaque bloc est limité.
En effet, il y a quelques années c'était de l'ordre de 100000. Mais ça a
dû s'améliorer.
Par contre, il est possible de changer des bits,
dans un sens seulement, pour changer le contenu d'un bloc.
En effet, l'écriture consiste à mettre à zéro un bit précédemment à un,
mais pour revenir à un il faut effacer.
Donc, la couche FTL/NFTL remappe les blocs en essayant de répartir
"l'usure" sur tous les blocs.
Compris. Est-ce géré par l'OS ou le contrôleur de mémoire flash ?
Pour les disques durs, le problème est autre: le format de stockage
physique est différent du format des données envoyées, d'une part,
Que voulez-vous dire ?
et d'autre part, le taux d'erreur est très élevé.
Bah, les techniques de redondance à base d'ECC ne sont pas faites pour
les chiens. La preuve, ça marche plutôt bien.
Les données sont donc compressées
Par le contrôleur intégré ? Jamais entendu parler, auriez-vous une
référence ?
Ça me paraît hautement improbable : on aurait une capacité variable en
fonction des données stockées.
Comme on ne peut pas savoir à l'avance la taille nécessaire pour
stocker un bloc compressé + les données redondantes, le bloc est
remappé à l'endroit ou il y a la place de le stocker.
Dites, vous ne seriez pas en train de confondre le boulot du contrôleur
interne avec les systèmes de fichiers qui utilisent la compression à la
volée ?
D'après IBM (maintenant Hitachi):
"The majority of disk drives manufactured today use an addressing scheme
where the data sectors are identified to the host system by a logical
block number (LBN). In operation, the host computer sends a list of
logical block numbers to be written or read. The disk drive converts these
values into zone, cylinder, head and sector (ZCHS) values."
Les "logical blocs numbers" ne sont clairement pas des emplacements
physiques...
Maiss il n'est pas dit que les secteurs de numéros LBA consécutifs ne
sont pas globalement rangés séquentiellement. S'ils ne l'étaient pas,
les efforts des OS et systèmes de fichiers pour limiter la fragmentation
seraient vains puisque ceux-ci n'ont aucun moyen de connaître la
position réelle des secteurs.
Ben voyons. Vous, vous n'avez pas dû faire beaucoup de mesures de débit. Le fait est là : le débit d'un disque dur soutenu décroit au fur et à mesure qu'on avance dans les numéros de secteurs et donc qu'on s'éloigne de la périphérie des plateaux.
C'est physiquement vrai, mais il n'y a que sur un disque neuf que c'est vrai au niveau user. Voir plus bas...
Etonnant, j'ai tout un tas de disques qui sont loin d'être neufs et ils ont tous un profil de décroissance continue ou par paliers du débit en fonction du numéro de secteur. Par ailleurs on peut voir ces même courbes sur les sites de test de matériel comme Hardware.fr.
Faites des mesures, vous dis-je. Les faits sont têtus.
Pour des questions de vitesse d'accès, on essaye de faire en sorte que le secteur n+1 ne soit "pas trop loin" du secteur n, mais c'est tout.
Vous parlez d'entrelacement (interleaving) ? C'est au contraire cette technique utilisée avec les disquettes et les disques ST506 (aussi dénommé MFM/RLL, impoprement) a été abandonnée avec l'intégration du contrôleur dans les disques IDE et SCSI. Depuis le facteur d'entrelacement est de 1 (pas d'entrelacement) car c'est ce qui permet le meilleur débit soutenu : pas besoin de sauter n secteurs physiques pour accéder au secteur logique suivant.
Il [le contrôleur interne] remappe les secteurs défectueux. Pourquoi en remapperait-il d'autres ?
Parce que les techniques de stockage actuelles sont très peu fiables et que les données ne sont pas stockées dans le format envoyé par l'OS.
De quoi parlez-vous ? Des techniques de détection et correction d'erreur (ECC) ? Qu'est-ce que ça a à voir avec la position des secteurs ?
Dans le cas des flash, le problème est que le nombre d'effacement possible pour chaque bloc est limité.
En effet, il y a quelques années c'était de l'ordre de 100000. Mais ça a dû s'améliorer.
Par contre, il est possible de changer des bits, dans un sens seulement, pour changer le contenu d'un bloc.
En effet, l'écriture consiste à mettre à zéro un bit précédemment à un, mais pour revenir à un il faut effacer.
Donc, la couche FTL/NFTL remappe les blocs en essayant de répartir "l'usure" sur tous les blocs.
Compris. Est-ce géré par l'OS ou le contrôleur de mémoire flash ?
Pour les disques durs, le problème est autre: le format de stockage physique est différent du format des données envoyées, d'une part,
Que voulez-vous dire ?
et d'autre part, le taux d'erreur est très élevé.
Bah, les techniques de redondance à base d'ECC ne sont pas faites pour les chiens. La preuve, ça marche plutôt bien.
Les données sont donc compressées
Par le contrôleur intégré ? Jamais entendu parler, auriez-vous une référence ? Ça me paraît hautement improbable : on aurait une capacité variable en fonction des données stockées.
Comme on ne peut pas savoir à l'avance la taille nécessaire pour stocker un bloc compressé + les données redondantes, le bloc est remappé à l'endroit ou il y a la place de le stocker.
Dites, vous ne seriez pas en train de confondre le boulot du contrôleur interne avec les systèmes de fichiers qui utilisent la compression à la volée ?
D'après IBM (maintenant Hitachi): "The majority of disk drives manufactured today use an addressing scheme where the data sectors are identified to the host system by a logical block number (LBN). In operation, the host computer sends a list of logical block numbers to be written or read. The disk drive converts these values into zone, cylinder, head and sector (ZCHS) values." Les "logical blocs numbers" ne sont clairement pas des emplacements physiques...
Maiss il n'est pas dit que les secteurs de numéros LBA consécutifs ne sont pas globalement rangés séquentiellement. S'ils ne l'étaient pas, les efforts des OS et systèmes de fichiers pour limiter la fragmentation seraient vains puisque ceux-ci n'ont aucun moyen de connaître la position réelle des secteurs.
