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.
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.
C'est la traduction télécom, du moins pour la partie brouillage des données. Pour la partie brouillage des adresses, cela ne me gêne pas si tu parles de:
"indirections", "réordonnancent des secteurs", traduisent mieux l'idée.
Je connais d'ailleurs ça moins bien que le brouillage des données.
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.
D'accord pour les indirections (brouillage des adresses), mais la fonction de brouillage des données n'est pas systématiquement implémentée Í ma connaissance.
pehache <pehache.7@gmail.com> wrote:
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.
C'est la traduction télécom, du moins pour la partie brouillage des
données.
Pour la partie brouillage des adresses, cela ne me gêne pas si tu parles
de:
"indirections", "réordonnancent des secteurs", traduisent mieux l'idée.
Je connais d'ailleurs ça moins bien que le brouillage des données.
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.
D'accord pour les indirections (brouillage des adresses), mais la
fonction de brouillage des données n'est pas systématiquement
implémentée Í ma connaissance.
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.
C'est la traduction télécom, du moins pour la partie brouillage des données. Pour la partie brouillage des adresses, cela ne me gêne pas si tu parles de:
"indirections", "réordonnancent des secteurs", traduisent mieux l'idée.
Je connais d'ailleurs ça moins bien que le brouillage des données.
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.
D'accord pour les indirections (brouillage des adresses), mais la fonction de brouillage des données n'est pas systématiquement implémentée Í ma connaissance.
pehache
Le 17/03/2021 Í 11:35, pehache a écrit :
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.
En fait on ne parle peut-être pas de la même chose !
Le 17/03/2021 Í 11:35, pehache a écrit :
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.
En fait on ne parle peut-être pas de la même chose !
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.
En fait on ne parle peut-être pas de la même chose !
Marc SCHAEFER
pehache wrote:
En fait on ne parle peut-être pas de la même chose !
Effectivement. Brouillage des adresses (pour ne pas réutiliser trop souvent les mêmes blocs) et brouillage des données (pour ne pas écrire trop souvent les mêmes bits), voire éviter des séquences d'écriture qui fatiguent.
pehache <pehache.7@gmail.com> wrote:
En fait on ne parle peut-être pas de la même chose !
Effectivement. Brouillage des adresses (pour ne pas réutiliser trop
souvent les mêmes blocs) et brouillage des données (pour ne pas écrire
trop souvent les mêmes bits), voire éviter des séquences d'écriture qui
fatiguent.
En fait on ne parle peut-être pas de la même chose !
Effectivement. Brouillage des adresses (pour ne pas réutiliser trop souvent les mêmes blocs) et brouillage des données (pour ne pas écrire trop souvent les mêmes bits), voire éviter des séquences d'écriture qui fatiguent.
pehache
Le 17/03/2021 Í 12:21, Marc SCHAEFER a écrit :
pehache wrote:
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.
C'est la traduction télécom, du moins pour la partie brouillage des données.
Dans le langage commun ça fait plutÍ´t penser aux nazis qui brouillaient Radio-Londres :-)
Pour la partie brouillage des adresses, cela ne me gêne pas si tu parles de:
"indirections", "réordonnancent des secteurs", traduisent mieux l'idée.
Je connais d'ailleurs ça moins bien que le brouillage des données.
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.
D'accord pour les indirections (brouillage des adresses), mais la fonction de brouillage des données n'est pas systématiquement implémentée Í ma connaissance.
En fait je n'avais pas compris que tu parlais de deux choses différentes. Le "brouillage des données" (en fait un chiffrement ?) dans les SSD pour des raisons "physiques" je ne connaissais pas.
Le 17/03/2021 Í 12:21, Marc SCHAEFER a écrit :
pehache <pehache.7@gmail.com> wrote:
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.
C'est la traduction télécom, du moins pour la partie brouillage des
données.
Dans le langage commun ça fait plutÍ´t penser aux nazis qui brouillaient
Radio-Londres :-)
Pour la partie brouillage des adresses, cela ne me gêne pas si tu parles
de:
"indirections", "réordonnancent des secteurs", traduisent mieux l'idée.
Je connais d'ailleurs ça moins bien que le brouillage des données.
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.
D'accord pour les indirections (brouillage des adresses), mais la
fonction de brouillage des données n'est pas systématiquement
implémentée Í ma connaissance.
En fait je n'avais pas compris que tu parlais de deux choses différentes.
Le "brouillage des données" (en fait un chiffrement ?) dans les SSD pour
des raisons "physiques" je ne connaissais pas.
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.
C'est la traduction télécom, du moins pour la partie brouillage des données.
Dans le langage commun ça fait plutÍ´t penser aux nazis qui brouillaient Radio-Londres :-)
Pour la partie brouillage des adresses, cela ne me gêne pas si tu parles de:
"indirections", "réordonnancent des secteurs", traduisent mieux l'idée.
Je connais d'ailleurs ça moins bien que le brouillage des données.
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.
D'accord pour les indirections (brouillage des adresses), mais la fonction de brouillage des données n'est pas systématiquement implémentée Í ma connaissance.
En fait je n'avais pas compris que tu parlais de deux choses différentes. Le "brouillage des données" (en fait un chiffrement ?) dans les SSD pour des raisons "physiques" je ne connaissais pas.
Marc SCHAEFER
pehache wrote:
Le "brouillage des données" (en fait un chiffrement ?) dans les SSD pour des raisons "physiques" je ne connaissais pas.
C'est un chiffrement, faible. Je te laisse regarder les 2 références (la 1ère étant malheureusement derrière un paywall).
pehache <pehache.7@gmail.com> wrote:
Le "brouillage des données" (en fait un chiffrement ?) dans les SSD pour
des raisons "physiques" je ne connaissais pas.
C'est un chiffrement, faible. Je te laisse regarder les 2 références (la
1ère étant malheureusement derrière un paywall).
Le "brouillage des données" (en fait un chiffrement ?) dans les SSD pour des raisons "physiques" je ne connaissais pas.
C'est un chiffrement, faible. Je te laisse regarder les 2 références (la 1ère étant malheureusement derrière un paywall).
Brice
Le 17 mars 2021 Í 12:56, pehache a raconté :
Dans le langage commun ça fait plutÍ´t penser aux nazis qui brouillaient Radio-Londres :-)
Tous les belligérants brouillaient les émissions radio de l'ennemi. Les américains étaient et sont toujours très fort. Les chinois et les russes sont Í leur niveau :) Cordialement, -- B. Graignic
Le 17 mars 2021 Í 12:56, pehache a raconté :
Dans le langage commun ça fait plutÍ´t penser aux nazis qui brouillaient
Radio-Londres :-)
Tous les belligérants brouillaient les émissions radio de l'ennemi.
Les américains étaient et sont toujours très fort. Les chinois et les
russes sont Í leur niveau :)
Cordialement,
--
B. Graignic
enlever-bgraig@wanadoo.fr
Dans le langage commun ça fait plutÍ´t penser aux nazis qui brouillaient Radio-Londres :-)
Tous les belligérants brouillaient les émissions radio de l'ennemi. Les américains étaient et sont toujours très fort. Les chinois et les russes sont Í leur niveau :) Cordialement, -- B. Graignic
Michel
Le 16/03/2021 Í 23:30, Pascal Hambourg a écrit :
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ: - déposer le SSD du NVR - le placer dans le rack ( de ma tour sous Debian ) - regarder et noter le contenu d'une dizaine de blocs - réinstaller le SSD dans le NVR - le formater - le redéposer et le réinstaller dans le rack - comparer le contenu de ces mêmes blocks Si tout est passé Í 0, c'est bon, le formatage suffit, mais sinon, lancer fstrim depuis le rack avant de réinstaller de SSD dans le NVR. Ça tourne depuis 2 mois, et je suis Í 32% d'occupation, mais je pourrai faire ce test dans quelques jours afin d'avoir des réponses... que je ne manquerai pas de donner ici. Merci Í tous pour vos informations.
Le 16/03/2021 Í 23:30, Pascal Hambourg a écrit :
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ:
- déposer le SSD du NVR
- le placer dans le rack ( de ma tour sous Debian )
- regarder et noter le contenu d'une dizaine de blocs
- réinstaller le SSD dans le NVR
- le formater
- le redéposer et le réinstaller dans le rack
- comparer le contenu de ces mêmes blocks
Si tout est passé Í 0, c'est bon, le formatage suffit, mais sinon,
lancer fstrim depuis le rack avant de réinstaller de SSD dans le NVR.
Ça tourne depuis 2 mois, et je suis Í 32% d'occupation, mais je pourrai
faire ce test dans quelques jours afin d'avoir des réponses... que je ne
manquerai pas de donner ici.
Ç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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ: - déposer le SSD du NVR - le placer dans le rack ( de ma tour sous Debian ) - regarder et noter le contenu d'une dizaine de blocs - réinstaller le SSD dans le NVR - le formater - le redéposer et le réinstaller dans le rack - comparer le contenu de ces mêmes blocks Si tout est passé Í 0, c'est bon, le formatage suffit, mais sinon, lancer fstrim depuis le rack avant de réinstaller de SSD dans le NVR. Ça tourne depuis 2 mois, et je suis Í 32% d'occupation, mais je pourrai faire ce test dans quelques jours afin d'avoir des réponses... que je ne manquerai pas de donner ici. Merci Í tous pour vos informations.
Pascal Hambourg
Le 17/03/2021 Í 18:59, Michel a écrit :
Le 16/03/2021 Í 23:30, Pascal Hambourg a écrit :
Le 15/03/2021 Í 13:30, Michel a écrit :
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ: - déposer le SSD du NVR - le placer dans le rack ( de ma tour sous Debian ) - regarder et noter le contenu d'une dizaine de blocs - réinstaller le SSD dans le NVR - le formater - le redéposer et le réinstaller dans le rack - comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le formatage. J'opterais pour une approche plus systématique : lecture de tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela peut se faire assez simplement avec badblocks en lui faisant faire un test de vérification en lecture avec le motif 0. badblocks -v -t 0 -o /dev/null /dev/sdxy
Le 17/03/2021 Í 18:59, Michel a écrit :
Le 16/03/2021 Í 23:30, Pascal Hambourg a écrit :
Le 15/03/2021 Í 13:30, Michel a écrit :
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ:
- déposer le SSD du NVR
- le placer dans le rack ( de ma tour sous Debian )
- regarder et noter le contenu d'une dizaine de blocs
- réinstaller le SSD dans le NVR
- le formater
- le redéposer et le réinstaller dans le rack
- comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le
formatage. J'opterais pour une approche plus systématique : lecture de
tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela
peut se faire assez simplement avec badblocks en lui faisant faire un
test de vérification en lecture avec le motif 0.
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ: - déposer le SSD du NVR - le placer dans le rack ( de ma tour sous Debian ) - regarder et noter le contenu d'une dizaine de blocs - réinstaller le SSD dans le NVR - le formater - le redéposer et le réinstaller dans le rack - comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le formatage. J'opterais pour une approche plus systématique : lecture de tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela peut se faire assez simplement avec badblocks en lui faisant faire un test de vérification en lecture avec le motif 0. badblocks -v -t 0 -o /dev/null /dev/sdxy
Michel
Le 18/03/2021 Í 20:44, Pascal Hambourg a écrit :
Le 17/03/2021 Í 18:59, Michel a écrit :
Le 16/03/2021 Í 23:30, Pascal Hambourg a écrit :
Le 15/03/2021 Í 13:30, Michel a écrit :
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ: - déposer le SSD du NVR - le placer dans le rack ( de ma tour sous Debian ) - regarder et noter le contenu d'une dizaine de blocs - réinstaller le SSD dans le NVR - le formater - le redéposer et le réinstaller dans le rack - comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le formatage. J'opterais pour une approche plus systématique : lecture de tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela peut se faire assez simplement avec badblocks en lui faisant faire un test de vérification en lecture avec le motif 0. badblocks -v -t 0 -o /dev/null /dev/sdxy
Ah oui, super idée ( que je ne connaissais pas ). Je viens de faire un test sur un des SSD de ma tour, c'est un peu long ( bien sÍ»r ) mais c'est exactement ce qu'il me faut ;) Je pense "opérer" ce week-end, je donnerai ici les résultats. Merci beaucoup
Le 18/03/2021 Í 20:44, Pascal Hambourg a écrit :
Le 17/03/2021 Í 18:59, Michel a écrit :
Le 16/03/2021 Í 23:30, Pascal Hambourg a écrit :
Le 15/03/2021 Í 13:30, Michel a écrit :
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ:
- déposer le SSD du NVR
- le placer dans le rack ( de ma tour sous Debian )
- regarder et noter le contenu d'une dizaine de blocs
- réinstaller le SSD dans le NVR
- le formater
- le redéposer et le réinstaller dans le rack
- comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le
formatage. J'opterais pour une approche plus systématique : lecture de
tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela
peut se faire assez simplement avec badblocks en lui faisant faire un
test de vérification en lecture avec le motif 0.
badblocks -v -t 0 -o /dev/null /dev/sdxy
Ah oui, super idée ( que je ne connaissais pas ). Je viens de faire un
test sur un des SSD de ma tour, c'est un peu long ( bien sͻr ) mais
c'est exactement ce qu'il me faut ;)
Je pense "opérer" ce week-end, je donnerai ici les résultats.
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.
En résumé, il faudrait, lorsque le SSD sera Í 80% de remplissage environ: - déposer le SSD du NVR - le placer dans le rack ( de ma tour sous Debian ) - regarder et noter le contenu d'une dizaine de blocs - réinstaller le SSD dans le NVR - le formater - le redéposer et le réinstaller dans le rack - comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le formatage. J'opterais pour une approche plus systématique : lecture de tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela peut se faire assez simplement avec badblocks en lui faisant faire un test de vérification en lecture avec le motif 0. badblocks -v -t 0 -o /dev/null /dev/sdxy
Ah oui, super idée ( que je ne connaissais pas ). Je viens de faire un test sur un des SSD de ma tour, c'est un peu long ( bien sÍ»r ) mais c'est exactement ce qu'il me faut ;) Je pense "opérer" ce week-end, je donnerai ici les résultats. Merci beaucoup
Michel
Le 18/03/2021 Í 20:53, Michel a écrit :
Le 18/03/2021 Í 20:44, Pascal Hambourg a écrit : - comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le formatage. J'opterais pour une approche plus systématique : lecture de tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela peut se faire assez simplement avec badblocks en lui faisant faire un test de vérification en lecture avec le motif 0. badblocks -v -t 0 -o /dev/null /dev/sdxy
Ah oui, super idée ( que je ne connaissais pas ). Je viens de faire un test sur un des SSD de ma tour, c'est un peu long ( bien sÍ»r ) mais c'est exactement ce qu'il me faut ;) Je pense "opérer" ce week-end, je donnerai ici les résultats. Merci beaucoup
Bon, j'ai un peu avancé, et ce fut une surprise. J'ai déposé le SSD du NVR. Installé sur la tour, j'ai trouvé 2 partitions, la première de 5 Go en ext3, et la principale de 252 Go en vfat! df -h Taille Utilisé Libre Uti% /dev/sdh1 4,9G 13M 4,6G 1% ( ext3 ) /dev/sdh2 252G 241G 11G 96% ( vfat ) De plus, dès le formatage, dans cette partition vfat sont créés 15 répertoires ( dir00000 Í dir00014 ) contenant chacun 128 fichiers de 128 Mo vides ( file00000.dat Í file00127.dat ). C'est dans ces fichiers que sont enregistrées les vidéos, dans un format propriétaire. Pour les blocs occupés: badblocks -v -t 0 -o /dev/null /dev/sdh2 Checking blocks 0 to 263361576 Checking for bad blocks in read-only mode Testing with pattern 0x00: done Pass completed, 118017102 bad blocks found. (0/0/118017102 errors) soit 118017102 blocs Í zéro sur 263361576 Donc pour résumer, j'en suis Í 33% d'occupation d'après le système, et environ 45% de blocs Í zéro. Si tout continue dans les mêmes proportions, il n'y aurait plus de blocs libres vers 70 Í 75% de remplissage ( donné par le NVR ), et lÍ , je dépose le SSD, j'efface tout les répertoires de sdx2, je lance fstrim sur cette partition, je réinstalle le SSD dans le NVR et reformate. Est-ce réaliste ou idiot ?
Le 18/03/2021 Í 20:53, Michel a écrit :
Le 18/03/2021 Í 20:44, Pascal Hambourg a écrit :
- comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le
formatage. J'opterais pour une approche plus systématique : lecture de
tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela
peut se faire assez simplement avec badblocks en lui faisant faire un
test de vérification en lecture avec le motif 0.
badblocks -v -t 0 -o /dev/null /dev/sdxy
Ah oui, super idée ( que je ne connaissais pas ). Je viens de faire un
test sur un des SSD de ma tour, c'est un peu long ( bien sͻr ) mais
c'est exactement ce qu'il me faut ;)
Je pense "opérer" ce week-end, je donnerai ici les résultats.
Merci beaucoup
Bon, j'ai un peu avancé, et ce fut une surprise. J'ai déposé le SSD du
NVR. Installé sur la tour, j'ai trouvé 2 partitions, la première de 5 Go
en ext3, et la principale de 252 Go en vfat!
De plus, dès le formatage, dans cette partition vfat sont créés 15
répertoires ( dir00000 Í dir00014 ) contenant chacun 128 fichiers de 128
Mo vides ( file00000.dat Í file00127.dat ).
C'est dans ces fichiers que sont enregistrées les vidéos, dans un format
propriétaire.
Pour les blocs occupés:
badblocks -v -t 0 -o /dev/null /dev/sdh2
Checking blocks 0 to 263361576
Checking for bad blocks in read-only mode
Testing with pattern 0x00: done
Pass completed, 118017102 bad blocks found. (0/0/118017102 errors)
soit 118017102 blocs Í zéro sur 263361576
Donc pour résumer, j'en suis Í 33% d'occupation d'après le système, et
environ 45% de blocs Í zéro.
Si tout continue dans les mêmes proportions, il n'y aurait plus de blocs
libres vers 70 Í 75% de remplissage ( donné par le NVR ), et lÍ , je
dépose le SSD, j'efface tout les répertoires de sdx2, je lance fstrim
sur cette partition, je réinstalle le SSD dans le NVR et reformate.
Le 18/03/2021 Í 20:44, Pascal Hambourg a écrit : - comparer le contenu de ces mêmes blocks
A condition de choisir des blocs qui ne vont pas être écrits par le formatage. J'opterais pour une approche plus systématique : lecture de tous les blocs pour déterminer combien sont ou ne sont pas Í zéro. Cela peut se faire assez simplement avec badblocks en lui faisant faire un test de vérification en lecture avec le motif 0. badblocks -v -t 0 -o /dev/null /dev/sdxy
Ah oui, super idée ( que je ne connaissais pas ). Je viens de faire un test sur un des SSD de ma tour, c'est un peu long ( bien sÍ»r ) mais c'est exactement ce qu'il me faut ;) Je pense "opérer" ce week-end, je donnerai ici les résultats. Merci beaucoup
Bon, j'ai un peu avancé, et ce fut une surprise. J'ai déposé le SSD du NVR. Installé sur la tour, j'ai trouvé 2 partitions, la première de 5 Go en ext3, et la principale de 252 Go en vfat! df -h Taille Utilisé Libre Uti% /dev/sdh1 4,9G 13M 4,6G 1% ( ext3 ) /dev/sdh2 252G 241G 11G 96% ( vfat ) De plus, dès le formatage, dans cette partition vfat sont créés 15 répertoires ( dir00000 Í dir00014 ) contenant chacun 128 fichiers de 128 Mo vides ( file00000.dat Í file00127.dat ). C'est dans ces fichiers que sont enregistrées les vidéos, dans un format propriétaire. Pour les blocs occupés: badblocks -v -t 0 -o /dev/null /dev/sdh2 Checking blocks 0 to 263361576 Checking for bad blocks in read-only mode Testing with pattern 0x00: done Pass completed, 118017102 bad blocks found. (0/0/118017102 errors) soit 118017102 blocs Í zéro sur 263361576 Donc pour résumer, j'en suis Í 33% d'occupation d'après le système, et environ 45% de blocs Í zéro. Si tout continue dans les mêmes proportions, il n'y aurait plus de blocs libres vers 70 Í 75% de remplissage ( donné par le NVR ), et lÍ , je dépose le SSD, j'efface tout les répertoires de sdx2, je lance fstrim sur cette partition, je réinstalle le SSD dans le NVR et reformate. Est-ce réaliste ou idiot ?
