Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
nombre réponses : 25

#0 Re : -1 »  Ubuntu-fr: signaler des erreurs et aider à améliorer le site » Hier à 22:41

L_d_v_c@
Réponses : 1437

Salut à tous et désolé. Je suis tombé sur un bogue de Thunar 1.2.3 qui m'a induit en erreur plus haut :
Il fallait surtout comprendre que j'ai galéré ces derniers jours à cause de l'affichage Thunar 1.2.3 qui m'a affiché Mo à la place de Mio …
588Mio ←→ 616Mo
Mais Thunar affiche 588Mo (ce qui est faux, et je suspectais Brasero ou Linux Mint à tors d'ajouter du code …)
édit : Je ne comprends plus rien, j'avais une différence de 307 200 ko mais la différence 616-588 Mo = 28 Mo … je me couche, désolé. fatigué.

#1 Re : -1 »  Topic des lève-tôt [partie 9] » Le 02/03/2015, à 12:52

L_d_v_c@
Réponses : 4748

The level of assurance rigor increases from EAL1 (lowest) to EAL7 (highest). Assurance to EAL7 involves formal verification of the software product using mathematical models and theorem proving. A software product developed according to a protection profile is certified to a specific EAL level by a US government-approved Common Criteria Testing Lab (CCTL).

Le niveau d' assurance augmente de rigueur EAL1 (le plus bas) à EAL7 (le plus élevé). L'assurance à EAL7 implique la vérification formelle du produit de logiciel à l'aide de modèles mathématiques et de théorèmes. Un logiciel développé selon un profil de protection est certifiée à un niveau EAL spécifique par un laboratoire d'essais de Critères Communs US approuvé par le gouvernement (CCTL).

#2 Re : -1 »  Topic des lève-tôt [partie 9] » Le 02/03/2015, à 13:38

L_d_v_c@
Réponses : 4748

En plus Lynx secure fonctionne sur les processeurs Open sources français Leon3 et surement le Leon4 en demandant gentiment.

http://www.tomshardware.fr/articles/sparc-leon3,1-19528.html a écrit :

Un processeur pour l’espace

Gaisler a travaillé avec l’ESA (European Space Agency) pour que son processeur puisse être utilisé dans l’espace. Une version spécifique du Leon 3 existe donc, dédiée à l’exploration spatiale. Le Leon 3 "espace" contient des circuits de correction des erreurs en interne, qui permettent de détecter et corriger les problèmes pour une fiabilité maximale des calculs.

D'un autre coté : les processeurs Kalray devrait tout révolutionner et faire mettre à la poubelle les processeurs AMD et Intel moins performant comme les i7 -980X (130 Watts !!!!!!!!!).

Les processeurs multicoeurs en comptent généralement 4 ou 8 . Chez Kalray, nous avons une architecture disruptive pouvant compter jusqu’à 256 cœurs en 28 namonètres avec des clusters de 16 processeurs VLIW à très faible consommation et d’autres processeurs pour gérer les échanges de données – architecture qui nous permettra d’ici 2 ans d’aller jusqu’à 1024 cœurs en technologie 20 nanomètres. En consommant moins de 10 watts, le MPPA 256 permet de réaliser des économies d’énergie d’un facteur 100 par rapport à d’autres familles de processeurs.
* une capacité de calcul de 230 milliards d’opérations par seconde (0,23 teraflops) avec une consommation inférieure à 10 Watts pour [le] MPPA 256.

#5 Re : -1 »  Topic des lève-tôt [partie 9] » Le 04/03/2015, à 14:29

L_d_v_c@
Réponses : 4748

Pour les SSD le paramètre 241 Lifetime_Write_GiB doit renseigner rapidement de l'usure.
Bien à force d'installer, j'ai affaibli un SSD Kingston 60 Go qui ne va plus qu'à 900 ko/s … (à moins que ce soit le PC portable d'occasion qui a une panne intermittente, ou ne supporterait pas les SSD malgré le mode IDE compatible.

Quelqu'un a-t-il tenté de Réinitialiser et nettoyer un SSD s'il-vous-plaît ?

Bonne journée wink

#6 Re : -1 »  Topic des lève-tôt [partie 9] » Le 04/03/2015, à 20:23

L_d_v_c@
Réponses : 4748

Attention, commande dangereuse censée effacer le SSD et afficher le SSD à l'écran si différent de zéro …

sudo dd if=/dev/zero of=/dev/sda bs=1M ; cat /dev/sda 

Tiens, il reste des informations sur le SSD …
1425496576.jpg
J'ai loupé un paramètre pour effacer le SSD (en /dev/sda) … ou alors le SSD est protégé en écriture ?

J'ai trouvé ! il y a une EMP qui a dû exploser dans le département ! hmm
Ah non, on dirait que les ordinateurs des autres fonctionnent à peu près …

#7 Re : -1 »  Topic des lève-tôt [partie 9] » Le 04/03/2015, à 20:46

L_d_v_c@
Réponses : 4748

Je m'auto-réponds, apparemment j'ai loupé une option :
Attention, commande dangereuse censée effacer le SSD …

sudo dd if=/dev/zero of=/dev/sda bs=1M conv=notrunc

L’argument « conv=notrunc » permet de ne pas limiter la taille du fichier de sortie.

#9 Re : -1 »  Topic des lève-tôt [partie 9] » Le 05/03/2015, à 07:41

L_d_v_c@
Réponses : 4748

Comment faisait un Amiga 1200 pour avoir un OS multitâche préemptif plus rapide que mon PC (le PC avec une carte graphique monstrueuse d'au moins 256 Mo) en n'utilisant que (2197152-1800000) environs 300 ko de RAM pour afficher l'écran, le gestionnaire de fenêtres et l'environnement de Bureau WorkBench 3.0, et de faire tourner les programmes, il restait 1,8 Mo de RAM, on pouvait faire plein de chose, ouvrir un traitement de texte, lancer Octamed Sound Studio. Je suis dégoûté.

Je pense que les 10% de l'AmigaOS développé en assembleur avec les 99% développés en C et 1% développé en script était vraiment une bonne trouvaille.

Les PC modernes peuvent calculer les fractales plus vite que l'Amiga d'autrefois. À part ça, je ne calcule pas de fractales (lourds calculs mathématiques) tous les jours.

#10 Re : -1 »  Topic des lève-tôt [partie 9] » Le 05/03/2015, à 09:17

L_d_v_c@
Réponses : 4748
souen a écrit :

Hé quelqu'un saurait-il me dire si en passant d'une alimentation de 1250W
à une alimentation de 750W si dans ce cas je peux avoir une baisse des performances
des taux de transfert des données sur mon disque ssd?

Tu t'es trompé ?
Tu veux passer d'une alimentation de 125W à 75W ? lol
Parles-tu d'un ordinateur ou d'un chauffage de chambre ? hmm D'un four ? hmm

#11 Re : -1 »  Topic des lève-tôt [partie 9] » Le 05/03/2015, à 16:18

L_d_v_c@
Réponses : 4748
souen a écrit :

okay merci pr vos éclairages. J'ai le taux de transfert qui a baissé d'une manière significative
et je cherche à savoir d'où cela peut venir. Je ne le ressens pas vraiment à l'utilisation mais bon je m'interroge.
Peut-être tout simplement l'usure.

Ok. HDD ? SSD ? USB ?

#12 Re : -1 »  Topic des lève-tôt [partie 9] » Le 05/03/2015, à 16:39

L_d_v_c@
Réponses : 4748
PPdM a écrit :

@ludo
Pourquoi tu ne réinstalle pas un Ubuntu studio 14.04 standard, il fonctionne parfaitement, y compris sur des portables, le 12.04 est largement obsolète me mis a jour, essayes de faire simple tu te feras moins chier

Your current Hardware Enablement Stack (HWE) is going out of support
on 2014-08-07.  After this date security updates for critical parts (kernel
and graphics stack) of your system will no longer be available.

For more information, please see:
http://wiki.ubuntu.com/1204_HWE_EOL

Vive les LTS … non, ce n'est pas possible que tout le monde reçoive ça.
Full LTS or not full LTS ? Bon, je ne comprends rien, c'est en anglais.

De toute façon la 14.04 ne passe pas sur mon ordinateur, enfin c'est inutilisable.

#13 Re : -1 »  Topic des lève-tôt [partie 9] » Le 05/03/2015, à 23:00

L_d_v_c@
Réponses : 4748
souen a écrit :

ssd
message d'origine:

souen a écrit :

Hé quelqu'un saurait-il me dire si en passant d'une alimentation de 1250W
à une alimentation de 750W si dans ce cas je peux avoir une baisse des performances
des taux de transfert des données sur mon disque ssd?

Désolé, j'étais distrait.
Si tu aperçois la courbes des SSD et leur usure ici  tu comprendras vite fait.

J'ai conclu :

moi … a écrit :

Si les publicités indiquaient que les performances diminuaient de moitié à 13% d'usure du nombre de cycle des SSD (ce qui est mesuré et représenté sur les courbes), aurions-nous acheté des SSD ?
PS : sur les graphiques la durée de vie asymptotique des disques est de 25% du nombre de cycles annoncés.

#14 Re : -1 »  Topic des lève-tôt [partie 9] » Hier à 08:42

L_d_v_c@
Réponses : 4748

Salut.

#15 Re : -1 »  Topic des lève-tôt [partie 9] » Hier à 09:50

L_d_v_c@
Réponses : 4748
souen a écrit :

donc sûrement l'usure - il a plus ou moins une année ce disque

Le fil original : Obsolescence programmée des SSD (explications SLC, MLC, TLC)

#16 Re : -1 »  Topic des lève-tôt [partie 9] » Hier à 13:32

L_d_v_c@
Réponses : 4748

Tout peut apparaître bizarre quand on cherche à comprendre la disponibilité processeur (en fait je découvre cet univers auquel je n'ai jamais pris le temps de décortiquer: Linux).

dd if=/dev/zero bs=1M count=1024 | md5sum
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB) copiéscd573cfaace07e7949bc0c46028904ff  -
, 4,48334 s, 239 MB/s

dd if=/dev/zero bs=1M count=1024 | md5sum
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 4,28376 s, 251 MB/s
cd573cfaace07e7949bc0c46028904ff  -

dd if=/dev/zero bs=1M count=1024 | md5sum
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB) copiéscd573cfaace07e7949bc0c46028904ff  -
, 3,65426 s, 294 MB/s

pourquoi dd m'a mangé un code retour la première fois et pas les suivantes ?

La disponibilité du disque SSD dans le système (ordinateur + Linux) :

dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 1,79852 s, 149 MB/s

Alors que la machine accède physiquement au même disque :

sudo hdparm -t --direct /dev/sda 

/dev/sda:
 Timing O_DIRECT disk reads: 636 MB in  3.00 seconds = 211.88 MB/sec

L'utilisation n'est qu'à 70% de ce que peut faire l'ordinateur … ?

#17 Re : -1 »  Topic des lève-tôt [partie 9] » Hier à 18:12

L_d_v_c@
Réponses : 4748

Bon, j'ai perdu quelques semaines à cause de ce bogue d'affichage dans Thunar 1.2.3 !!!!!!!!!!!

moi a écrit :

Ce n'est qu'un bogue de Thunar 1.2.3, mais je prouve la partition cachée :

J'ai une autre approche : en février j'ai gravé une iso de 588Mo (voilà le bogue de Thunar) archlinux_20150201 avec Brasero depuis Linux Mint 17 chez l'informaticien de ma ville. Très vite je me suis rendu compte d'une partition fantôme de 31 Mo.

Il y a une partition cachée sur le CD (visible avec  que j'arrive enfin à voir à moitié depuis Ubuntu, j'insiste sur la vérification par md5sum /dev/sr0 QUI DOIT indiquer la même chose que l'ISO, pas d'histoire de byte-padding ou de bit-padding je pense (qui est transparent puisque propre au média, l'autre nom étant l'entrelacement des données avec sommes de contrôles sur les supports optiques depuis les CD des années 1982 qui font 1 Go environs et dont seulement 650Mo puis 700Mo étaient exploitables).

fdisk -l /dev/sr0
Note : taille de secteur 2048 (et non pas 512)

Disque /dev/sr0 : 616 Mo, 616566784 octets             #pas normal puisque l'image fait 588 Mo !!! tu vas comprendre …
255 têtes, 63 secteurs/piste, 18 cylindres, total 301058 secteurs
Unités = secteurs de 1 * 2048 = 2048 octets
Taille de secteur (logique / physique) : 2048 octets / 2048 octets
taille d'E/S (minimale / optimale) : 2048 octets / 2048 octets
Identifiant de disque : 0x25a9244e

Périphérique Amorçage  Début         Fin      Blocs    Id. Système
/dev/sr0p1   *           0     1204223     2408448    0  Vide
/dev/sr0p2             252       63739      126976   ef  EFI (FAT-12/16/32)

Un bogue de Thunar qui affiche Mo à la place de Mio !
588Mio ←→ 616Mo

Et c'est comme ça que j'ai cru graver 588 Mo et que je me suis retrouvé avec 616 Mo !

Je hurle de colère, même si je suis rassuré.

J'ai gravé 588 Mio soient 616 Mo !
1425661153.png

#18 Re : -1 »  Topic des lève-tôt [partie 9] » Hier à 22:35

L_d_v_c@
Réponses : 4748
moko138 a écrit :
Ludo a écrit :

Il y a une partition cachée sur le CD (visible avec  que j'arrive enfin à voir à moitié depuis Ubuntu, j'insiste sur la vérification par md5sum /dev/sr0 QUI DOIT indiquer la même chose que l'ISO, pas d'histoire de byte-padding ou de bit-padding je pense (qui est transparent puisque propre au média, l'autre nom étant l'entrelacement des données avec sommes de contrôles sur les supports optiques depuis les CD des années 1982 qui font 1 Go environs et dont seulement 650Mo puis 700Mo étaient exploitables).

Allô ? On est censé y comprendre quelque chose ?

Les CD/DVD ont des données entrelacées et des sommes de contrôles.
Un CD de 650Mo fait pas loin de 1 Go de données brutes, mais pour le rendre résistant à la poussière, les données ne se suivent pas.

Bref, j'ai toujours fait md5sum /dev/lecteur pour comparer les MD5 et vérifier la gravure et ça fonctionnait mais l'ami informaticien sur Paris me dit qu'il ne faut pas faire comme ça.

un ami a écrit :


la vérification par md5sum /dev/sr0 QUI DOIT indiquer la même chose que l'ISO...

NON c'est FAUX Ludo, j'insiste aussi.

la vérification par md5sum de /dev/sr0 NE PEUX PAS INDIQUER la même
chose que le md5sum sur l'ISO, sauf dans certains cas très rares ou
on a égalité à l'octet prêt des tailles du fichier ISO et du /dev/sr0

C'est dû aux octets de fin de blocs (remplissage, padding ou trailing
blocks). /dev/sdX est généralement plus grand que le fichier image ISO.

3 exemples du md5sum sur le fichier image ISO de Slitaz 5.0

  # md5sum slitaz-5.0-rc2.iso
  283876031d414506fbe697f02f023bde  slitaz-5.0-rc2.iso

  # cat slitaz-5.0-rc2.iso | md5sum
  283876031d414506fbe697f02f023bde  -

  # <slitaz-5.0-rc2.iso md5sum
  283876031d414506fbe697f02f023bde  -

Là, pas de problèmes les md5sum sont identiques, bien évidement.

Pour faire un md5sum sur /dev/sr0, il FAUT impérativement limiter la
lecture au nombre d'octets du fichier image ISO (ici 44040192 octets)

# ls -l slitaz-5.0-rc2.iso
-rw-rw-r-- 1 cde cde 44040192 19 mai    2014 slitaz-5.0-rc2.iso
                     ^^^^^^^^
                Taille de l'image ISO

La seule VRAIE façon de faire le md5sum sur /dev/sro est donc la
suivante (Cette méthode fonctionnera dans TOUS LES CAS) :

  dd if=/dev/sr0 | head -c 44040192 | md5sum

Pour faire un CMP avec /dev/sr0, ce serait comme cela :

  cmp -n 44040192 /dev/sr0 slitaz-5.0-rc2.iso

Pour un DIFF, se serait comme cela :

  diff <( dd if=/dev/sr0 | head -c 44040192 ) slitaz-5.0-rc2.iso


Quelques liens qui abordent ce sujet :

http://twiki.org/cgi-bin/view/Wikilearn … terBurning

http://unix.stackexchange.com/questions … f-cds-dvds

http://unix.stackexchange.com/questions … out-errors

Il fallait surtout comprendre que j'ai galéré ces derniers jours à cause de l'affichage Thunar 1.2.3 qui m'a affiché Mo à la place de Mio ! wink
588Mio ←→ 616Mo
Mais Thunar affiche 588Mo (ce qui est faux, et je suspectais Brasero ou Linux Mint d'ajouter du code … sad )

#19 -1 »  Bogue dans Thunar 1.2.3 (confusion Mo et Mio !!!) » Hier à 18:22

L_d_v_c@
Réponses : 0

Bonjour,

Croyez-vous que la confusion entre Mo et Mio puisse faire perdre plusieurs jours et rendre malade ?

La preuve en image avec mon témoignage :

L_d_v_c@ a écrit :

Bon, j'ai perdu quelques semaines à cause de ce bogue d'affichage dans Thunar 1.2.3 !!!!!!!!!!!

moi a écrit :

Ce n'est qu'un bogue de Thunar 1.2.3, mais je prouve la partition cachée qui semble normale, partition EFI) :

J'ai une autre approche : en février j'ai gravé une iso de 588Mo (voilà le bogue de Thunar) archlinux_20150201 avec Brasero depuis Linux Mint 17 chez l'informaticien de ma ville. Très vite je me suis rendu compte d'une partition fantôme de 31 Mo.

Il y a une partition cachée sur le CD (visible avec  que j'arrive enfin à voir à moitié depuis Ubuntu, j'insiste sur la vérification par md5sum /dev/sr0 QUI DOIT indiquer la même chose que l'ISO, pas d'histoire de byte-padding ou de bit-padding je pense (qui est transparent puisque propre au média, l'autre nom étant l'entrelacement des données avec sommes de contrôles sur les supports optiques depuis les CD des années 1982 qui font 1 Go environs et dont seulement 650Mo puis 700Mo étaient exploitables).

fdisk -l /dev/sr0
Note : taille de secteur 2048 (et non pas 512)

Disque /dev/sr0 : 616 Mo, 616566784 octets             #pas normal puisque l'image fait 588 Mo !!! tu vas comprendre …
255 têtes, 63 secteurs/piste, 18 cylindres, total 301058 secteurs
Unités = secteurs de 1 * 2048 = 2048 octets
Taille de secteur (logique / physique) : 2048 octets / 2048 octets
taille d'E/S (minimale / optimale) : 2048 octets / 2048 octets
Identifiant de disque : 0x25a9244e

Périphérique Amorçage  Début         Fin      Blocs    Id. Système
/dev/sr0p1   *           0     1204223     2408448    0  Vide
/dev/sr0p2             252       63739      126976   ef  EFI (FAT-12/16/32)

Un bogue de Thunar qui affiche Mo à la place de Mio !
588Mio ←→ 616Mo

Et c'est comme ça que j'ai cru graver 588 Mo et que je me suis retrouvé avec 616 Mo !

Je hurle de colère, même si je suis rassuré.

J'ai gravé 588 Mio soient 616 Mo !
http://pix.toile-libre.org/upload/thumb/1425661153.png

1425661153.png

#20 Re : -1 »  Obsolescence programmée des SSD (explications SLC, MLC, TLC) » Le 04/03/2015, à 14:53

L_d_v_c@
Réponses : 23

Réinitialiser et nettoyer un SSD.

http://www.moncoinnumerique.fr/spip.php?article31 a écrit :

Une dégradation rapide des performances

La dégradation des performances des SSD de première et deuxième génération est bien connue des experts :

Si vous comprenez l’anglais, l’article de John Savill, de WindowsITPro, l’explique clairement.

Mais je vous renvoie aussi à l’excellent article de Sébastien de BHMag. Il explique non seulement cet aspect navrant des choses, mais tout ce qui est utile sur les SSD, si vous débarquez dans ce domaine.

Pour OCZ, cet article de Hardware.fr met les points sur les i.

Mais bon, au prix d’un SSD, encore aujourd’hui, on ne peut pas se contenter de le voir bien fonctionner quelques mois seulement, n’est-ce pas !

L’article de John Savill
L’excellent article de Sébastien de BHMag
L'article de Hardware.fr (qui) met les points sur les i.

*Mon deuxième SSD Kingston SVP200 (60 Go) se traîne à moins de 900 Ko/s sad mais il peut y avoir un autre problème, impossible d'installer GNU/Linux ou BSD … (l'ordinateur est d'occasion et une panne intermittente n'est pas à exclure).

#21 Re : -1 »  Obsolescence programmée des SSD (explications SLC, MLC, TLC) » Le 05/03/2015, à 16:31

L_d_v_c@
Réponses : 23
Nairolf21 a écrit :

Le problème avec l'obsolescence programmée, c'est l'obscurantisme.
Comment fais-tu pour savoir si une entreprise fabrique volontairement des produits à faible durée de vie ? Comme cela est caché, il est impossible de connaître les motivations profonde de l'entreprise. Et du coup, la paranoïa peut s'ajouter, et tu peux suspecter presque tout produit d'être fabriqué avec de l'obsolescence programmé...

Pour l'électronique, tout est contrôlé par statistiques, et tests de vieillissement accélérés (température, pression, fréquence).
Un fabriquant possède forcément ce genre de courbes avant la commercialisation, mais les commerciaux les cachent.
dégradations des performances d'écritures avec l'usure en pourcentage
L'article : Comparatif SSD : Intel, OCZ, Samsung, Silicon Power, SuperTalent

Si les publicités indiquaient que les performances diminuaient de moitié à 13% d'usure du nombre de cycle des SSD (ce qui est mesuré et représenté sur les courbes), aurions-nous acheté des SSD ?
PS : sur les graphiques la durée de vie asymptotique des disques est de 25% du nombre de cycles annoncés.

#23 Re : -1 »  Obsolescence programmée des SSD (explications SLC, MLC, TLC) » Hier à 09:57

L_d_v_c@
Réponses : 23

J'essayerai de tenter ça plus tard : ATA Secure Erase (pour remettre à zéro un SSD avec hdparm)

#24 Re : -1 »  Obsolescence programmée des SSD (explications SLC, MLC, TLC) » Hier à 11:33

L_d_v_c@
Réponses : 23
SilentStorm a écrit :

Les tests en laboratoire ont montré que contrairement a une idée reçu, les SSD peuvent supporté des quantités de données écrite très importante pendant une longue période.

En écriture intensive 24h/24 en écrivant dessus 20 Go chaque jour, 7j/7 tous les ans sans jamais s’arrêter, les SSD actuel tienne déjà 5 ans ! et ça c'est avec de l'écriture intensive, soit bien + que ce que vous allez écrire ! En moyenne on va écrire environ 1 ou 2 Go de données chaque jour sur un SSD (c'est un moyenne, parfois moins, parfois plus), ils peuvent donc tenir environ 100 a 150 ans en écrivant normalement pour utilisation normale de la plupart des gens.

Les réduction d'accès en écriture pour un SSD sont totalement inutile, c'est de la paranoia je trouve. Vous aurez changé plusieurs fois de SSD avant qu'il soit en panne.

Je demande les sources. Quels laboratoires ? Quelle génération de SSD ? Les SLC ? les MLC ? les TLC ?

Sur cet article vérifiable, de vraies mesures coté utilisateur.

http://linuxfr.org/users/fcartegnie/journaux/ssd-samsung-840-le-fiasco-annonce-du-tlc a écrit :

Journal SSD Samsung 840: le fiasco annoncé du TLC ?
Posté par fcartegnie le 06/10/14 à 17:16. Licence CC by-sa
Tags :     ssd  6 oct. 2014

Pour ceux qui ne seraient pas informés ou qui n'auraient pas constaté le problème sur leur propre modèle,
tous les SSD Samsung à base de TLC (840/840 EVO) ont un gros pépin: La vitesse de lecture s'écroule sur les zones de flash qui ne sont pas accédées depuis plusieurs semaines.

Sujet sur Overclock.net

Personnellement, la lecture brut d'un volume rarement accédé donne des sueurs.

cat /dev/mapper/SSDVol-foobar | pv > /dev/null

-> 2,29MiB/s

Apparemment la mémoire TLC était très bien dans les tests lors de la conception et de Wear Leveling, donc en écriture soutenue, mais personne ne s'était aperçu que les cellules ne répondaient plus correctement si elle n'étaient pas écrites régulièrement.

Actuellement, la réponse du support Samsung à ce problème est (je vous laisse constater l'arnaque):
- De reformater le disque complètement avec l'outil Samsung secure-erase.
- Si ça ne corrige pas le problème de retourner le disque.

Vive les sauvegardes… tant que rsync ne fait pas de checksum sur le fichier hmm