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 ?
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 ?
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 ?
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.
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.
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.
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.
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.
badblocks -v -t 0 -o /dev/null /dev/sdxy
Le 19/03/2021 Í 10:16, Michel a écrit :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.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Dans ce cas, ça équivaudrait Í un formatage + un fstrim, non?
Le 19/03/2021 Í 10:16, Michel a écrit :
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.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Dans ce cas, ça équivaudrait Í un formatage + un fstrim, non?
Le 19/03/2021 Í 10:16, Michel a écrit :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.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Dans ce cas, ça équivaudrait Í un formatage + un fstrim, non?
Je viens de faire le tour de la chose ( enfin, je pense ;)
Pour le formatage du SSD, il faut que je le formate sur le système ( il
formate et créé des répertoires remplis de fichiers vides ), puis que je
le dépose pour effectuer un TRIM de la partition 2, et enfin que je le
réinstalle.
C'est la seule solution qui donne le résultat recherché.
Je viens de faire le tour de la chose ( enfin, je pense ;)
Pour le formatage du SSD, il faut que je le formate sur le système ( il
formate et créé des répertoires remplis de fichiers vides ), puis que je
le dépose pour effectuer un TRIM de la partition 2, et enfin que je le
réinstalle.
C'est la seule solution qui donne le résultat recherché.
Je viens de faire le tour de la chose ( enfin, je pense ;)
Pour le formatage du SSD, il faut que je le formate sur le système ( il
formate et créé des répertoires remplis de fichiers vides ), puis que je
le dépose pour effectuer un TRIM de la partition 2, et enfin que je le
réinstalle.
C'est la seule solution qui donne le résultat recherché.
Le 20/03/2021 Í 15:39, Michel a écrit :Je viens de faire le tour de la chose ( enfin, je pense ;)
Pour le formatage du SSD, il faut que je le formate sur le système ( il
formate et créé des répertoires remplis de fichiers vides ), puis que je
le dépose pour effectuer un TRIM de la partition 2, et enfin que je le
réinstalle.
C'est la seule solution qui donne le résultat recherché.
Quel résultat ?
Si les fichiers créés occupent 95% de la partition, alors le TRIM ne
pourra agir au mieux que sur les 5% restants.
Le 20/03/2021 Í 15:39, Michel a écrit :
Je viens de faire le tour de la chose ( enfin, je pense ;)
Pour le formatage du SSD, il faut que je le formate sur le système ( il
formate et créé des répertoires remplis de fichiers vides ), puis que je
le dépose pour effectuer un TRIM de la partition 2, et enfin que je le
réinstalle.
C'est la seule solution qui donne le résultat recherché.
Quel résultat ?
Si les fichiers créés occupent 95% de la partition, alors le TRIM ne
pourra agir au mieux que sur les 5% restants.
Le 20/03/2021 Í 15:39, Michel a écrit :Je viens de faire le tour de la chose ( enfin, je pense ;)
Pour le formatage du SSD, il faut que je le formate sur le système ( il
formate et créé des répertoires remplis de fichiers vides ), puis que je
le dépose pour effectuer un TRIM de la partition 2, et enfin que je le
réinstalle.
C'est la seule solution qui donne le résultat recherché.
Quel résultat ?
Si les fichiers créés occupent 95% de la partition, alors le TRIM ne
pourra agir au mieux que sur les 5% restants.
Le 19/03/2021 Í 15:13, Michel a écrit :Le 19/03/2021 Í 10:16, Michel a écrit :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!
Je ne trouve aucune référence Í l'application de TRIM/discard par la
commande usuelle de formatage en FAT, mkfs.fat. Néanmoins il me semble
que le pilote FAT du noyau Linux supporte fstrim.
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 ).
Comment ça, "vides" ? D'après df ils occupent bien 240 Gio, donc ne
peuvent pas être vides, d'autant plus qu'Í ma connaissance FAT ne
supporte pas les fichiers "creux" (sparse) ou préalloués mais non
initialisés (avec fallocate).
Je connais trois façons pour Linux de donner une taille Í un fichier :
1) La plus évidente, y écrire des données.
2) Créer un fichier "creux" dont les "trous" sont comptés dans la taille
apparente mais n'occupent pas d'espace dans le système de fichiers. On
peut donc créer un fichier creux dont la taille dépasse celle du système
de fichiers.
3) créer un fichier préalloué (fallocate) en allouant des blocs sans les
initialiser avec des données. Contrairement aux trous des fichiers
creux, les blocs alloués non initialisés sont comptés dans l'espace
occupé et on ne peut pas dépasser la taille du système de fichiers. Je
suppose que les blocs non initialisés sont éligibles au TRIM/discard
avec fstrim puisqu'ils ne contiennent pas de données valides.
Les méthodes 2) et 3) sont beaucoup plus rapides et économes en écriture
que la méthode 1) ne sont possibles qu'avec les systèmes de fichiers qui
les supportent. La lecture d'une zone "creuse" ou non initialisée
retourne des 0 et est aussi très rapide puisqu'il n'y a pas de lecture
physique.
C'est dans ces fichiers que sont enregistrées les vidéos, dans un format
propriétaire.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Si c'est le cas, alors d'autres données y ont été écrites depuis puisque
badblocks retourne que seulement 45% des blocs sont Í 0.
Combien de temps prend le formatage ? S'il écrit 240 Gio de 0, ça doit
prendre au moins le même temps que badblocks Í mis pour les lire.
Le 19/03/2021 Í 15:13, Michel a écrit :
Le 19/03/2021 Í 10:16, Michel a écrit :
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!
Je ne trouve aucune référence Í l'application de TRIM/discard par la
commande usuelle de formatage en FAT, mkfs.fat. Néanmoins il me semble
que le pilote FAT du noyau Linux supporte fstrim.
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 ).
Comment ça, "vides" ? D'après df ils occupent bien 240 Gio, donc ne
peuvent pas être vides, d'autant plus qu'Í ma connaissance FAT ne
supporte pas les fichiers "creux" (sparse) ou préalloués mais non
initialisés (avec fallocate).
Je connais trois façons pour Linux de donner une taille Í un fichier :
1) La plus évidente, y écrire des données.
2) Créer un fichier "creux" dont les "trous" sont comptés dans la taille
apparente mais n'occupent pas d'espace dans le système de fichiers. On
peut donc créer un fichier creux dont la taille dépasse celle du système
de fichiers.
3) créer un fichier préalloué (fallocate) en allouant des blocs sans les
initialiser avec des données. Contrairement aux trous des fichiers
creux, les blocs alloués non initialisés sont comptés dans l'espace
occupé et on ne peut pas dépasser la taille du système de fichiers. Je
suppose que les blocs non initialisés sont éligibles au TRIM/discard
avec fstrim puisqu'ils ne contiennent pas de données valides.
Les méthodes 2) et 3) sont beaucoup plus rapides et économes en écriture
que la méthode 1) ne sont possibles qu'avec les systèmes de fichiers qui
les supportent. La lecture d'une zone "creuse" ou non initialisée
retourne des 0 et est aussi très rapide puisqu'il n'y a pas de lecture
physique.
C'est dans ces fichiers que sont enregistrées les vidéos, dans un format
propriétaire.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Si c'est le cas, alors d'autres données y ont été écrites depuis puisque
badblocks retourne que seulement 45% des blocs sont Í 0.
Combien de temps prend le formatage ? S'il écrit 240 Gio de 0, ça doit
prendre au moins le même temps que badblocks Í mis pour les lire.
Le 19/03/2021 Í 15:13, Michel a écrit :Le 19/03/2021 Í 10:16, Michel a écrit :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!
Je ne trouve aucune référence Í l'application de TRIM/discard par la
commande usuelle de formatage en FAT, mkfs.fat. Néanmoins il me semble
que le pilote FAT du noyau Linux supporte fstrim.
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 ).
Comment ça, "vides" ? D'après df ils occupent bien 240 Gio, donc ne
peuvent pas être vides, d'autant plus qu'Í ma connaissance FAT ne
supporte pas les fichiers "creux" (sparse) ou préalloués mais non
initialisés (avec fallocate).
Je connais trois façons pour Linux de donner une taille Í un fichier :
1) La plus évidente, y écrire des données.
2) Créer un fichier "creux" dont les "trous" sont comptés dans la taille
apparente mais n'occupent pas d'espace dans le système de fichiers. On
peut donc créer un fichier creux dont la taille dépasse celle du système
de fichiers.
3) créer un fichier préalloué (fallocate) en allouant des blocs sans les
initialiser avec des données. Contrairement aux trous des fichiers
creux, les blocs alloués non initialisés sont comptés dans l'espace
occupé et on ne peut pas dépasser la taille du système de fichiers. Je
suppose que les blocs non initialisés sont éligibles au TRIM/discard
avec fstrim puisqu'ils ne contiennent pas de données valides.
Les méthodes 2) et 3) sont beaucoup plus rapides et économes en écriture
que la méthode 1) ne sont possibles qu'avec les systèmes de fichiers qui
les supportent. La lecture d'une zone "creuse" ou non initialisée
retourne des 0 et est aussi très rapide puisqu'il n'y a pas de lecture
physique.
C'est dans ces fichiers que sont enregistrées les vidéos, dans un format
propriétaire.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Si c'est le cas, alors d'autres données y ont été écrites depuis puisque
badblocks retourne que seulement 45% des blocs sont Í 0.
Combien de temps prend le formatage ? S'il écrit 240 Gio de 0, ça doit
prendre au moins le même temps que badblocks Í mis pour les lire.
Le 20/03/2021 Í 20:32, Pascal Hambourg a écrit :Le 19/03/2021 Í 15:13, Michel a écrit :Le 19/03/2021 Í 10:16, Michel a écrit :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 ).
Comment ça, "vides" ? D'après df ils occupent bien 240 Gio, donc ne
peuvent pas être vides, d'autant plus qu'Í ma connaissance FAT ne
supporte pas les fichiers "creux" (sparse) ou préalloués mais non
initialisés (avec fallocate).
Je connais trois façons pour Linux de donner une taille Í un fichier :
1) La plus évidente, y écrire des données.
2) Créer un fichier "creux" dont les "trous" sont comptés dans la taille
apparente mais n'occupent pas d'espace dans le système de fichiers. On
peut donc créer un fichier creux dont la taille dépasse celle du système
de fichiers.
3) créer un fichier préalloué (fallocate) en allouant des blocs sans les
initialiser avec des données. Contrairement aux trous des fichiers
creux, les blocs alloués non initialisés sont comptés dans l'espace
occupé et on ne peut pas dépasser la taille du système de fichiers. Je
suppose que les blocs non initialisés sont éligibles au TRIM/discard
avec fstrim puisqu'ils ne contiennent pas de données valides.
Pardon, je voulais dire, par vides, que les données ne semblent pas
modifiées sur le SSD, comme tu le dit au point 3.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Si c'est le cas, alors d'autres données y ont été écrites depuis puisque
badblocks retourne que seulement 45% des blocs sont Í 0.
Combien de temps prend le formatage ? S'il écrit 240 Gio de 0, ça doit
prendre au moins le même temps que badblocks Í mis pour les lire.
Oui, après avoir écrit ça, j'ai pensé comme toi, trop rapide pour être
vrai ;)
Le 20/03/2021 Í 20:32, Pascal Hambourg a écrit :
Le 19/03/2021 Í 15:13, Michel a écrit :
Le 19/03/2021 Í 10:16, Michel a écrit :
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 ).
Comment ça, "vides" ? D'après df ils occupent bien 240 Gio, donc ne
peuvent pas être vides, d'autant plus qu'Í ma connaissance FAT ne
supporte pas les fichiers "creux" (sparse) ou préalloués mais non
initialisés (avec fallocate).
Je connais trois façons pour Linux de donner une taille Í un fichier :
1) La plus évidente, y écrire des données.
2) Créer un fichier "creux" dont les "trous" sont comptés dans la taille
apparente mais n'occupent pas d'espace dans le système de fichiers. On
peut donc créer un fichier creux dont la taille dépasse celle du système
de fichiers.
3) créer un fichier préalloué (fallocate) en allouant des blocs sans les
initialiser avec des données. Contrairement aux trous des fichiers
creux, les blocs alloués non initialisés sont comptés dans l'espace
occupé et on ne peut pas dépasser la taille du système de fichiers. Je
suppose que les blocs non initialisés sont éligibles au TRIM/discard
avec fstrim puisqu'ils ne contiennent pas de données valides.
Pardon, je voulais dire, par vides, que les données ne semblent pas
modifiées sur le SSD, comme tu le dit au point 3.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Si c'est le cas, alors d'autres données y ont été écrites depuis puisque
badblocks retourne que seulement 45% des blocs sont Í 0.
Combien de temps prend le formatage ? S'il écrit 240 Gio de 0, ça doit
prendre au moins le même temps que badblocks Í mis pour les lire.
Oui, après avoir écrit ça, j'ai pensé comme toi, trop rapide pour être
vrai ;)
Le 20/03/2021 Í 20:32, Pascal Hambourg a écrit :Le 19/03/2021 Í 15:13, Michel a écrit :Le 19/03/2021 Í 10:16, Michel a écrit :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 ).
Comment ça, "vides" ? D'après df ils occupent bien 240 Gio, donc ne
peuvent pas être vides, d'autant plus qu'Í ma connaissance FAT ne
supporte pas les fichiers "creux" (sparse) ou préalloués mais non
initialisés (avec fallocate).
Je connais trois façons pour Linux de donner une taille Í un fichier :
1) La plus évidente, y écrire des données.
2) Créer un fichier "creux" dont les "trous" sont comptés dans la taille
apparente mais n'occupent pas d'espace dans le système de fichiers. On
peut donc créer un fichier creux dont la taille dépasse celle du système
de fichiers.
3) créer un fichier préalloué (fallocate) en allouant des blocs sans les
initialiser avec des données. Contrairement aux trous des fichiers
creux, les blocs alloués non initialisés sont comptés dans l'espace
occupé et on ne peut pas dépasser la taille du système de fichiers. Je
suppose que les blocs non initialisés sont éligibles au TRIM/discard
avec fstrim puisqu'ils ne contiennent pas de données valides.
Pardon, je voulais dire, par vides, que les données ne semblent pas
modifiées sur le SSD, comme tu le dit au point 3.
Serait-il possible que ces nombreux fichiers soient créés remplis de 0?
Si c'est le cas, alors d'autres données y ont été écrites depuis puisque
badblocks retourne que seulement 45% des blocs sont Í 0.
Combien de temps prend le formatage ? S'il écrit 240 Gio de 0, ça doit
prendre au moins le même temps que badblocks Í mis pour les lire.
Oui, après avoir écrit ça, j'ai pensé comme toi, trop rapide pour être
vrai ;)
Le 20/03/2021 Í 21:01, Michel a écrit :
Pardon, je voulais dire, par vides, que les données ne semblent pas
modifiées sur le SSD, comme tu le dit au point 3.
Sauf qu'Í ma connaissance Linux ne fait pas de préallocation avec FAT.
J'ai essayé avec fallocate, il écrit des 0 pour atteindre la taille
demandée.
Oui, après avoir écrit ça, j'ai pensé comme toi, trop rapide pour être
vrai ;)
Combient de temps dure le formatage par l'enregistreur ?
Le 20/03/2021 Í 21:01, Michel a écrit :
Pardon, je voulais dire, par vides, que les données ne semblent pas
modifiées sur le SSD, comme tu le dit au point 3.
Sauf qu'Í ma connaissance Linux ne fait pas de préallocation avec FAT.
J'ai essayé avec fallocate, il écrit des 0 pour atteindre la taille
demandée.
Oui, après avoir écrit ça, j'ai pensé comme toi, trop rapide pour être
vrai ;)
Combient de temps dure le formatage par l'enregistreur ?
Le 20/03/2021 Í 21:01, Michel a écrit :
Pardon, je voulais dire, par vides, que les données ne semblent pas
modifiées sur le SSD, comme tu le dit au point 3.
Sauf qu'Í ma connaissance Linux ne fait pas de préallocation avec FAT.
J'ai essayé avec fallocate, il écrit des 0 pour atteindre la taille
demandée.
Oui, après avoir écrit ça, j'ai pensé comme toi, trop rapide pour être
vrai ;)
Combient de temps dure le formatage par l'enregistreur ?