Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Matériel Ordinateur Stockage SSD en replacement d'un disque dur

SSD en replacement d'un disque dur

39 réponses
Avatar
Michel
Bonjour,

Pour de l'observation animalière, j'ai acheté il y a deux mois un
système de video surveillance tournant sous linux.
Il est composé d'un boÍ®tier NVR avec un HDD de 3 To et de 8 caméras
wifi, et il se pilote depuis en écran et une souris:
https://fr.aliexpress.com/item/32761992170.html

Le HDD vibre et chauffe pas mal ( le boÍ®tier n'est pas ventilé ) et je
l'ai remplacé par un SSD.
Le système est prévu pour écraser les plus vielles données, mais je
pense qu'avec ce SSD, ça va poser problème ( la fonction fstrim n'est
sans doute pas implémentée ).
Je pensais reformater ce SSD lorsqu'il atteindra environ 80% de
remplissage ( ça se fait depuis l'interface du système ), soit d'après
mes estimations, tous les 4 Í  6 mois.
Qu'en pensez-vous? Cela tourne depuis 2 mois avec 6 caméras et les
performances sont tout Í  fait correctes.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
Benoit
Ni vu ni connu, le 16 mars 2021 Í  12:07, pehache osa écrire :
Le 16/03/2021 Í  11:51, Benoit a écrit :
Je pensais reformater ce SSD lorsqu'il atteindra environ 80% de
remplissage ( ça se fait depuis l'interface du système ),

Ca ne sert Í  rien du tout. Du point de vue du contrÍ´leur du SSD, les
cellules qui contenaient des données contiennent toujours des données
après un reformatage.

Question bête : d'après ce que j'ai compris un SSD a de gros blocs de
données appartenant Í  différents fichiers et pour écrire dans un bloc il
doit le lire pour savoir o͹ il y a de la place en effaçant les données
inutilisées (plus de bout de fichiers) et y inscrire de nouvelles
données.

Pas exactement. Il ne doit pas le lire pour "savoir o͹ il y a de place",
mais parce que toute action d'écriture dans une cellule doit être
précédée de l'effacement de la cellule, mais l'effacement ne peut se
faire que sur un bloc entier. Donc pour écrire même un seul octet dans
le bloc le contrÍ´leur doit :
- copier le bloc dans une petite RAM locale
- effacer le bloc
- écrire l'octet dans la copie du bloc en RAM
- récrire le bloc entier depuis la RAM

Ok, j'avais donc compris un bout.
Mais quand il efface le bloc il le remplit avec quoi ? Tout ce qui est
inutilisé est plein de EOF ou EOB (Bout de fichier) ?
Maintenant si je le reformate, je lui dit que tous les blocs
sont vides. Il peut donc réécrire dedans en ignorant ce qu'il contient,
non ?

Oui, Í  condition que l'OS informe le contrÍ´leur que les blocs sont
vides. C'est le rÍ´le de la fonction TRIM. Ce qui suppose plusieurs choses
:
- que le SSD, l'interface, et l'OS, gèrent tous trois le TRIM
- que la commande de formatage envoie une commande TRIM au SSD
Quelle différence avec le reformatage d'un HDD ?

En l'absence de TRIM, aucune.

Je peux donc reformater sans lui dire qu'il est vide ! Alors, ͠ quoi
sert le reformatage sans TRIM ? C'est juste l'OS qui le sait dans son
coin qu'il y a de la place ?
Je sens que j'ai encore des questions sous le coude. ;-)
--
Benoͮt
La douleur des autres est tout Í  fait supportable, hors les cris.
Avatar
pehache
Le 16/03/2021 Í  12:22, Benoit a écrit :
Question bête : d'après ce que j'ai compris un SSD a de gros blocs de
données appartenant Í  différents fichiers et pour écrire dans un bloc il
doit le lire pour savoir o͹ il y a de la place en effaçant les données
inutilisées (plus de bout de fichiers) et y inscrire de nouvelles
données.

Pas exactement. Il ne doit pas le lire pour "savoir o͹ il y a de place",
mais parce que toute action d'écriture dans une cellule doit être
précédée de l'effacement de la cellule, mais l'effacement ne peut se
faire que sur un bloc entier. Donc pour écrire même un seul octet dans
le bloc le contrÍ´leur doit :
- copier le bloc dans une petite RAM locale
- effacer le bloc
- écrire l'octet dans la copie du bloc en RAM
- récrire le bloc entier depuis la RAM

Ok, j'avais donc compris un bout.
Mais quand il efface le bloc il le remplit avec quoi ? Tout ce qui est
inutilisé est plein de EOF ou EOB (Bout de fichier) ?

Je ne sais pas. Un effacement correspond probablement Í  une mise Í  zéro
de toutes les cellules (tension nulle), mais c'est Í  vérifier.
Maintenant si je le reformate, je lui dit que tous les blocs
sont vides. Il peut donc réécrire dedans en ignorant ce qu'il contient,
non ?

Oui, Í  condition que l'OS informe le contrÍ´leur que les blocs sont
vides. C'est le rÍ´le de la fonction TRIM. Ce qui suppose plusieurs choses
:
- que le SSD, l'interface, et l'OS, gèrent tous trois le TRIM
- que la commande de formatage envoie une commande TRIM au SSD
Quelle différence avec le reformatage d'un HDD ?

En l'absence de TRIM, aucune.

Je peux donc reformater sans lui dire qu'il est vide ! Alors, ͠ quoi
sert le reformatage sans TRIM ? C'est juste l'OS qui le sait dans son
coin qu'il y a de la place ?

Oui. En soi le (re)formatage d'une partition c'est juste la
réinitialisation de sa table d'allocation des fichiers.
Avatar
Pascal Hambourg
Le 16/03/2021 Í  15:09, pehache a écrit :
Le 16/03/2021 Í  12:22, Benoit a écrit :
Question bête : d'après ce que j'ai compris un SSD a de gros blocs de
données appartenant Í  différents fichiers et pour écrire dans un bloc il
doit le lire pour savoir o͹ il y a de la place en effaçant les données
inutilisées (plus de bout de fichiers) et y inscrire de nouvelles
données.

Pas exactement. Il ne doit pas le lire pour "savoir o͹ il y a de place",
mais parce que toute action d'écriture dans une cellule doit être
précédée de l'effacement de la cellule, mais l'effacement ne peut se
faire que sur un bloc entier.



Pour préciser un peu, il y a deux types de blocs :
- les blocs d'effacement, la plus petite unité qu'on peut effacer ;
- les blocs d'écriture appelés aussi "pages", la plus petite unité qu'on
peut écrire.
Un bloc d'effacement contient plusieurs pages qui sont toutes effacées
en même temps et qui peuvent être écrites indépendamment.
Donc pour écrire même un seul octet dans
le bloc le contrÍ´leur doit :
- copier le bloc dans une petite RAM locale
- effacer le bloc
- écrire l'octet dans la copie du bloc en RAM
- récrire le bloc entier depuis la RAM



Sauf qu'un SSD ne fait jamais ça, car c'est inefficace aussi bien en
terme de vitesse qu'en terme d'usure. Quand les données d'une page sont
modifiées, on écrit les nouvelles données dans une nouvelle page vierge
et on marque l'ancienne page comme invalide, comme quand elle est
marquée avec TRIM. Quand toutes les pages du bloc d'effacement sont
marquées invalides, on peut effacer le bloc et le rendre prêt pour de
nouvelles écritures. Eventuellement, s'il reste quelques pages contenant
des données valides dans un bloc, on peut les copier dans de nouvelles
pages d'autres blocs avant d'effacer le bloc. C'est la fonction
"ramasse-miettes" (garbage collector). L'objectif est de toujours
disposer d'un stock de pages vierges prêtes pour l'écriture. D'ailleurs
une partie de la capacité brute d'un SSD, de l'ordre de 10%, est
réservée notamment pour cela (et aussi pour remplacer les blocs
défectueux). Cela participe aussi au nivellement de l'usure (wear
levelling) qui a pour but d'éviter que certains blocs subissent plus de
cycles d'écriture/effacement que les autres.
Un effacement correspond probablement Í  une mise Í  zéro
de toutes les cellules (tension nulle), mais c'est Í  vérifier.

Traditionnellement depuis les EPROM (mémoire programmable) dont la
mémoire flash est l'évolution, l'effacement met tous les bits Í  1, et
l'écriture ou programmation met certains bits Í  0.
Avatar
Pascal Hambourg
Le 15/03/2021 Í  13:30, Michel a écrit :
Le 15/03/2021 Í  12:55, Pascal Hambourg a écrit :
Le 15/03/2021 Í  11:13, Michel a écrit :
Le 15/03/2021 Í  00:11, Pascal Hambourg a écrit :
Ça doit dépendre de quelle façon on formate. Par exemple les commandes
standard de formatage en ext2/3/4, Btrfs et XFS sous GNU/Linux font un
TRIM/discard de tous les blocs par défaut.

Y a-t'il un moyen de vérifier cette hypothèse après formatage dans le NVR?

Je n'en connais pas. Si le SSD annonce dans ses caractéristiques (hdparm
-I) que TRIM met les données Í  zéro, on peut vérifier si tout le contenu
hormis les méta-données est Í  0, mais c'est indirect.

Merci pour ces réponses.
Ce SSD accepte les commandes TRIM ( c'est un Crucial MX300 ), mais y
a-t'il un moyen de savoir si, après un reformatage depuis le système
linux fermé, les données ont bien été remises Í  0?

Si le TRIM est censé mettre les données Í  0, on peut vérifier si la
plupart des secteurs sont Í  0. Mais on ne peut pas distinguer ce cas du
cas o͹ toutes les données ont été écrites Í  0.
Avatar
pehache
Le 16/03/2021 Í  23:26, Pascal Hambourg a écrit :
Donc pour écrire même un seul octet dans
le bloc le contrÍ´leur doit :
- copier le bloc dans une petite RAM locale
- effacer le bloc
- écrire l'octet dans la copie du bloc en RAM
- récrire le bloc entier depuis la RAM



Sauf qu'un SSD ne fait jamais ça, car c'est inefficace aussi bien en
terme de vitesse qu'en terme d'usure.

Oui, mais c'était pour rester simple et éviter de rentrer dans tous les
détails de fonctionnement d'un coup.
Un effacement correspond probablement Í  une mise Í  zéro de toutes les
cellules (tension nulle), mais c'est Í  vérifier.

Traditionnellement depuis les EPROM (mémoire programmable) dont la
mémoire flash est l'évolution, l'effacement met tous les bits Í  1, et
l'écriture ou programmation met certains bits Í  0.

Ah mince, juste l'inverse :)
Avatar
Marc SCHAEFER
pehache wrote:
Oui, mais c'était pour rester simple et éviter de rentrer dans tous les
détails de fonctionnement d'un coup.

Il me semble que personne n'a parlé du brouillage souvent utilisé:
- pour répartir les écritures sur le périphérique (brouillage
d'adresse)
- pour assurer une répartition des 1 et 0 plus ou moins uniforme
Et il y a même eu des périphériques qui interprétaient
les métadonnées de filesystem pour décider de préemptivement `discard'
(trim) certains blocs.
Et parfois toute cette intelligence aboutit, comme avec les anciens
SSD Samsung, Í  des corruptions de données.
Traditionnellement depuis les EPROM (mémoire programmable) dont la
mémoire flash est l'évolution, l'effacement met tous les bits Í  1, et
l'écriture ou programmation met certains bits Í  0.

Ah mince, juste l'inverse :)

Avec brouillage, pas forcément 1-1 avec les données.
Avatar
pehache
Le 17/03/2021 Í  08:25, Marc SCHAEFER a écrit :
pehache wrote:
Oui, mais c'était pour rester simple et éviter de rentrer dans tous les
détails de fonctionnement d'un coup.

Il me semble que personne n'a parlé du brouillage souvent utilisé:

Je parlerais plutÍ´t d'indirections. "Brouillage" ça fait un peu "on ne
s'y retrouve plus" :)
- pour répartir les écritures sur le périphérique (brouillage
d'adresse)

Ou pour écrire dans un bloc libre quelconque, comme le disait Pascal.
- pour assurer une répartition des 1 et 0 plus ou moins uniforme

??
Traditionnellement depuis les EPROM (mémoire programmable) dont la
mémoire flash est l'évolution, l'effacement met tous les bits Í  1, et
l'écriture ou programmation met certains bits Í  0.

Ah mince, juste l'inverse :)

Avec brouillage, pas forcément 1-1 avec les données.

??
Avatar
Marc SCHAEFER
pehache wrote:
Je parlerais plutÍ´t d'indirections. "Brouillage" ça fait un peu "on ne
s'y retrouve plus" :)

En anglais scrambling. Je connais ça des télécommunications o͹ le
brouillage permet d'assurer les synchronisations en couche 1, lorsque
les données de la couche 2 ne changent pas suffisamment et qu'il n'y a
pas d'horloge encodée.
Pour les SSD, le brouillage est une fonction optionnelle, cela complique
évidemment la récupération de données, voir cet article:
https://www.sciencedirect.com/science/article/abs/pii/S1742287614001212
Ce n'est pas aussi sͻr qu'un chiffrement, ce n'est pas le but.
Avatar
Marc SCHAEFER
Marc SCHAEFER wrote:
Pour les SSD, le brouillage est une fonction optionnelle, cela complique
évidemment la récupération de données, voir cet article:
https://www.sciencedirect.com/science/article/abs/pii/S1742287614001212
Ce n'est pas aussi sͻr qu'un chiffrement, ce n'est pas le but.

Voir aussi cet article (disponible, lui, sans paywall), qui montre
comment fatiguer une mémoire flash, même lorsqu'un dispositif de
brouillage est utilisé:
https://people.inf.ethz.ch/omutlu/pub/flash-memory-programming-vulnerabilities_hpca17.pdf
(page 7)
Je cite: "Scrambling Workaround. To exert the maximum possible
interference, the malicious application needs to writespecic data values
to the SSD. One obstacle is that many SSDs internally scramble data
before storing the data in the flash memory [13, 22]. Scrambling
randomizes the number of 0s and 1s, to reduce the effects of data
pattern dependence on fash errors."
Fatiguer les flash -- ou même les DRAM -- est devenu un champ de
recherche de la sécurité depuis quelques années, dans le but de
démontrer qu'il est possible de modifier des bits de mémoire privilégiée
de manière contrÍ´lée.
Voir p.ex.:
https://wiki.alphanet.ch/Sandbox/MeltdownSpectreRowhammer#Rowhammer
Avatar
pehache
Le 17/03/2021 Í  09:25, Marc SCHAEFER a écrit :
pehache wrote:
Je parlerais plutÍ´t d'indirections. "Brouillage" ça fait un peu "on ne
s'y retrouve plus" :)

En anglais scrambling.

Oui OK, mais parfois la traduction directe d'un mot n'est pas très
heureuse dans le contexte. "Brouillage" en français ça sous-entend une
volonté de ne plus s'y retrouver, ce n'est pas du tout le cas ici.
"indirections", "réordonnancent des secteurs", traduisent mieux l'idée.
Pour les SSD, le brouillage est une fonction optionnelle,

A part peut-être dans les clé USB bas de gamme, je pense que c'est au
contraire systématiquement utilisé. Sans ça les SSD ne feraient pas long
feu.
1 2 3 4