La Fibre
Fonctionnement du forum => A lire avant de commencer... => 
Évolution de LaFibre.info, bugs et critiques => Discussion démarrée par: vivien le 18 novembre 2016 à 09:19:25
-
Savez-vous où sont les données du Forum LaFibre.info ?
Sur un serveur Dell chez Maxnod, avec nouveauté un disque SSD que voici :
(https://lafibre.info/images/materiel/201611_ssd_samsung_1.jpg)
Le 4 novembre le disque dur SATA de mon serveur m'a lâché :
Le disque dur du serveur LaFibre.info m'a compétemment lâché, après 4 ans et demi de bon services, je suis passé sur un serveur provisoire avec la sauvegarde de 9h45 de ce matin.
J'ai décidé de choisir un SSD pour remplacer le disque dur à plateau, car ils tombent rapidement en panne quand ils sont souvent sollicités et 4 ans et demi ce n'est pas mal comme endurance. Le choix du SSD s'est porté sur la gamme Samsun Pro :
Endurance sur de gros fichiers :
(https://lafibre.info/images/materiel/201611_ssd_samsung_5.png)
Malgré quelques baisse de régimes, le Samsung 840 Pro reste supérieur à ses concurrents (crédit : TechReport)
Endurance sur des petits fichiers :
(https://lafibre.info/images/materiel/201611_ssd_samsung_6.png)
Sur les petits fichiers, le Samsung 840 Pro tient toujours la dragée haute aux autres, tandis que le Kingston HyperX 3K Comp est à la peine (crédit : TechReport).
C'est également des SSD Samung qu'utilise Online sur ses serveurs :
Nous utilisons principalement des SSD Samsung série MZ7LN256HMJP (PM871a). C'est un dérivé en TLC des EVO avec un peu plus d'overprovisionning.
Ils ne sont pas disponibles sur le marché "normal", ce sont des références spécifiques disponibles uniquement en direct constructeur.
Nous avons essayé d'autres marques (notamment Intel et Micron) et n'avons jamais réussi à avoir une endurance convenable, pour un rapport fiabilité/performance/prix nettement inférieur.
Nous en avons déployé plusieurs dizaines de milliers depuis 18 mois, nous avons un taux de casse inférieur à 0,2% (une trentaine à peu près)
Arnaud
-
Depuis le 10 novembre, le forum est de nouveau hébergé chez Maxnod, mais avec un SSD :
Je démarre la migration du forum : A partir de 4h00 le forum sera en lecture seule le temps de l'opération et de la propagation des DNS...
Le SSD de LaFibre.info :
(https://lafibre.info/images/materiel/201611_ssd_samsung_2.jpg)
(https://lafibre.info/images/materiel/201611_ssd_samsung_3.jpg)
-
C'est un SSD qui a une garantie de 10ans ou 150 To écrit (la fin de la garantie arrive par le premier des deux qui est terminé)
(https://lafibre.info/images/materiel/201611_ssd_samsung_garantie_1.png)
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/materiel/201611_ssd_samsung_garantie.png) (https://lafibre.info/images/materiel/201611_ssd_samsung_garantie.pdf)
150 To sur 10 ans = 15 To par an = 41,06 Go par jour
J'ai donc pour objectif de tuner le serveur pour ne pas dépasser 41 Go par jour
-
Vous allez me dire que je suis fou, qu'un SSD à une durée de vie limitée quand on écrit plusieurs Go de données dessus.
J'ai fait plusieurs choses pour avoir une grande durée de vie :
1/ J'ai choisit un modèle sur-dimensionné de 512 Go : aujourd'hui je pourrait faire tenir tout sur un disque de 40 Go (avec même 1 Go d'espace libre) Or il est important que le SSD ait de nombreux blocs libre pour pouvoir répartir les écritures sur de nombreux blocs. Si sur un disque les 3/4 des données sont occupées et ne sont jamais effacées ou ré-écrites, seul 1/4 des blocs sont utilisés pour l'écriture. Là j'ai beaucoup de blocs libres (même si j'envisage d'utilisées un peu plus de données dans le futur avec des vidéos)
2/ Comme recommandé, j'ai laissé un peu plus de 10% du disque non partitionné, afin d'augmenter l'overprovisionning.
Extrait de la doc :
La fonction Over provisioning permet de redimensionner les partitions d’un lecteur. Les SSD fonctionnement mieux et durent plus longtemps lorsqu’ils disposent d’une grande quantité d’espace utilisable comme espace d’échange.
Durant les périodes d’inactivité, l’espace d’échange est utilisé pour effectuer en arrière-plan les tâches de maintenance courante du SSD (fonctions TRIM et Garbage Collection), ce qui permet au contrôleur SSD de préparer des blocs libres en vue d’une utilisation ultérieure. Dans la mesure où le SSD offre de meilleures performances lorsqu’il écrit dans des blocs libres, il en résulte une meilleure expérience utilisateur.
La fonction Over provisioning contribue à dégager de l’espace libre en redimensionnant les partitions d’un lecteur.
3/ J'ai mis des fichiers de log peu important dans un ramdisque (je perds les données à chaque reboot, mais les fichiers où j'ai besoin d'un historique sont toujours sur le SSD)
4/ Depuis hier, les données Smoking (les .rrd, fichiers qui sont ré-écrits toutes les 5 minutes) sont dans un RamDisque persistant, sauvegardé une fois par jour et avant tout reboot du serveur. Je vais publier les scripts que j'utilise si cela peut servir à d'autres. Les données SmokePing temporaire (les images) sont elles dans un RramDisque non persistant.
5/ vm.swappiness = 10 : Je passe swappiness de la valeur par défaut 60 à 10 : le swap est utilisé uniquement quand la mémoire est utilisée à plus de 90% (100-10) contre 40% par défaut (100-60). Cela diminue fortement l’utilisation du swap. Je n'ai mis que 1 Go de partition de swap sur le SSD.
6/ J'envisage de ne plus écrire les données d'un fichier modifié au bout de 30 seconde (la valeur par défaut), mais de 5 minutes. Ainsi la base de donnée, qui est modifiée des dizaines de fois par secondes ne sera plus écrite sur disque que toutes les 5 minutes et non toutes les 30 secondes.[/size]
-
Tu ne voudrais pas partager quelques graphs d'avant/après ? :)
-
2/ Comme recommandé, j'ai laissé un peu plus de 10% du disque non partitionné, afin d'augmenter l'overprovisionning.
Par rapport à ça...
On est bien d'accord qu'il faut que le contrôleur du SSD sache que tu as voulu faire de l'overprovisionning, et que tu utilises moins d'espace que la capacité totale. Sinon, le contrôleur va juste laisser cet espace inutilisé, sans y toucher...
De ce que j'ai compris (attention, je ne suis pas expert), le contrôleur du SSD ne sait pas comment tu partitionnes ton disque.
Du coup, comment ça se passe pour faire comprendre ça au contrôleur du SSD?
* Est-ce que tu utilises un outil du constructeur Samsung pour le configurer?
* Est-ce que le contrôleur détecte ça automatiquement d'une autre façon? Si oui, comment?
Autre question : pourquoi avoir limité l'overprovisionning autour de 10%, vu que tu as besoin de moins de 100Go sur un disque de 500Go? Tu ne pouvais pas monter à 30% ou 40% par exemple?
Leon.
-
D’après ce que j'ai compris, le SSD sait que personne n'a jamais écrit sur ces bloques. (cela ne me semble possible que si on est le premier utilisateur du SSD)
C'est donc pour cette raison que j'ai préféré faire un partitionnement classique : (l partition ft32, c'est pour le démarrage l'UEFI)
# parted -l
Modèle: ATA Samsung SSD 850 (scsi)
Disque /dev/sda : 512GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Numéro Début Fin Taille Système de fichiers Nom Fanions
1 1049kB 538MB 537MB fat32 démarrage
2 538MB 30,5GB 30,0GB ext4
3 30,5GB 31,5GB 1000MB linux-swap(v1)
4 31,5GB 452GB 420GB ext4
-
Tu ne voudrais pas partager quelques graphs d'avant/après ? :)
Données Smart du SSD neuf (avec l'utilitaire Samsung, sous Windows) :
(https://lafibre.info/images/materiel/201611_ssd_samsung_7.png)
Données Smart aujourd'hui, après 8 jours d'utilisation :
# smartctl -a /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.4.0-47-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: Samsung SSD 850 PRO 512GB
Serial Number: S39FNWAH978067B
LU WWN Device Id: 5 002538 d703ab405
Firmware Version: EXM02B6Q
User Capacity: 512 110 190 592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Fri Nov 18 09:45:14 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 265) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 263
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 4
177 Wear_Leveling_Count 0x0013 100 100 000 Pre-fail Always - 0
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 073 072 000 Old_age Always - 27
195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 0
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 251043383
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
255 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
-
Descriptions de certains attributs SMART des SSD Samsung :
- ID 5 Reallocated Sector Count : Nombre de secteurs ayant été réalloués. Quand le disque dur obtient une erreur de lecture/écriture/vérification sur un secteur, il note ce secteur comme réalloué et transfère les données vers un nouveau secteur situé dans une zone réservée spéciale.
- ID 9 Power-On Hours : Nombre d’heures pendant lequel le lecteur a été en fonctionnement. Cette valeur est un simple indicateur du comportement de l’utilisateur, et n’est pas directement liée à l’état de fonctionnement du lecteur. La valeur brute de cet attribut indique le nombre total d’heures (ou, selon le constructeur, de minutes ou de secondes) de fonctionnement du disque. Lorsque l’ordinateur est en mode de veille prolongée, la valeur Power-On Hours n'augmente pas.
- ID12 Power-on Count : Nombre de cycles de mise sous/hors tension complets du disque.
- ID 177 Wear Leveling Count : Représente le nombre d’opérations d’effacement effectuées sur le support (le nombre de fois qu’un bloc a été effacé).
- ID 179 Used Reserved Block Count : Représente le nombre total de blocs réservés ayant été utilisés suite à un échec d’une demande programme ou d’une demande d’effacement.
- ID 181 Program Fail Count : Nombre de demandes programme (d’écriture) ayant échoué.
- ID 182 Erase Fail Count : Nombre de demandes d’effacement ayant échoué.
- ID 183 Runtime Bad Count : Correspond à la somme de Program Fail Count et de Erase Fail Count. Cette valeur récapitulative représente le nombre total cumulé d’échecs de demandes programme et de demandes d’effacement.
- ID 187 Uncorrectable Error Count : Nombre total d’erreurs n’ayant pas pu être corrigées via ECC.
- ID 190 Air Flow Temperature : Température actuelle des puces NAND situées à l’intérieur du SSD.
- ID 195 ECC Error Rate : Nombre d’erreurs corrigibles. Nombre d’erreurs corrigées par le mécanisme interne de correction d’erreurs.
- ID 199 CRC Error Count : Nombre d'erreurs CRC (Cyclic Redundancy Check). Le moteur CRC utilise cet attribut pour comptabiliser le nombre de problèmes se produisant entre l'hôte et la mémoire flash DRAM ou NAND.
- ID 235 POR Recovery Count : Nombre de cas de mise hors tension soudaine. En cas de mise hors tension soudaine, le microcode doit récupérer l’ensemble des données de mappage et des données utilisateur lors de la prochaine mise sous tension. Cet attribut comptabilise le nombre de fois où cette séquence s’est produite.
- ID 241 Total LBAs Written (attribut SMART 241) : Représente la taille totale des blocs LBA (Logical Block Addressing) requis pour traiter l’ensemble des demandes d’écriture envoyées au SSD depuis l’hôte. Pour calculer la taille totale (en octets), il faut multiplier la valeur remontée par SMART par 512.
- ID 252 Vendor Specific (attribut SMART 252) : Pas d'information sur cet attribut disponible sur certains SSD Samsung.
J'ai déjà donc écrit en 8 jours 251043383 x 512 octets = 128,5 Go ?
Je suis étonné, car avec 36 Go de données restaurées + OS, cela fait 92,5 Go sur 8 jour, soit 11,5 Go par jour.
Or les fichiers RRD de SmokePing font 450 Mo. Si ils sont écrits en entier toutes les 5 minutes, cela fait 450 * 288 = 129,6 Go par jour d'écrit
16 Go = 16 000 000 000 octets.
Les détails ci-après sont renseignés pour chaque attribut SMART :
- ID : Nom décimal de l’attribut SMART.
- Description : Nom de l’attribut SMART.
- Seuil : Seuil à partir duquel la valeur normalisée est considérée comme « dépassant les spécifications ».
- Valeur actuelle : Valeur normalisée actuelle de l’attribut.
- Pire valeur : Valeur la plus médiocre signalée relativement au lecteur sélectionné pour un attribut donné.
- Données brutes : Valeur brute affectée à l’attribut SMART par le fabricant du lecteur.
- Status : Indique si le système peut ou non effectuer un traitement sur le lecteur.
-
Par rapport à ça...
On est bien d'accord qu'il faut que le contrôleur du SSD sache que tu as voulu faire de l'overprovisionning, et que tu utilises moins d'espace que la capacité totale. Sinon, le contrôleur va juste laisser cet espace inutilisé, sans y toucher...
De ce que j'ai compris (attention, je ne suis pas expert), le contrôleur du SSD ne sait pas comment tu partitionnes ton disque.
Du coup, comment ça se passe pour faire comprendre ça au contrôleur du SSD?
* Est-ce que tu utilises un outil du constructeur Samsung pour le configurer?
* Est-ce que le contrôleur détecte ça automatiquement d'une autre façon? Si oui, comment?
Autre question : pourquoi avoir limité l'overprovisionning autour de 10%, vu que tu as besoin de moins de 100Go sur un disque de 500Go? Tu ne pouvais pas monter à 30% ou 40% par exemple?
Leon.
Pour le coup, je pourrais répondre à tout ça avec précision (en y ajoutant mes spéculations sur comment cela devrait fonctionner).
Quoi qu'il en soit, le contrôleur n'a aucune raison de connaitre le partitionnement ou le filesystem. En fait le contrôleur ne sert à faire que la relation émulation secteur/piste (enfin numéro de bloc) et adressage linéaire des pages de la flash (blocs de 1024/2048/4096/8192/etc. octets).
Du genre (secteur,piste) = (10/12) => accès à la page de la flash à l'adresse 0x1012.
Lors d'une écriture même d'un seul octet dans le même secteur,piste/bloc, le contrôleur met la page initiale dans son garbage collector (le flags "prèt à être effacé") et réécrit les données+l'octet changé dans une nouvelle page qu'il sait libre (au pif 0x7835).
Du coup toutes lectures suivantes à (10/12) => accès à la page de la flash à l'adresse 0x7835.
En gros ce n'est qu'une espèce d'immense MMU avec translation d'adresse pour parler CPU.
Le garbage collector s'amuse en IDLE à regrouper les données pour toujours avoir un pool de secteurs effacés: quand on efface la flash, on ne peut pas effacer une seule page mais un groupe (genre 32/128 pages ensemble + contrainte sur l'écriture en parallèle, etc.).
Le trim c'est pratique pour marquer directement les secteurs utilisés d'un fichier effacé comme effacé au niveau du contrôleur (au lieu comme sur les FS sur DD de juste mettre un flag dans l'entête du fichier, et les secteurs seront bêtement réécrit).
-
On ne peut pas écrire un seul octet sur un périphérique "bloc". ;)
-
Autre question : pourquoi avoir limité l'overprovisionning autour de 10%, vu que tu as besoin de moins de 100Go sur un disque de 500Go? Tu ne pouvais pas monter à 30% ou 40% par exemple?
Pour de futur usages, notamment vidéo : aujourd'hui je mets des liens Youtube des vidéos qui sont malheureusement supprimés par les marques.
Exemples : toutes les vidéos de B&You ont été supprimés par Bouygues Telecom
Bref, pour avoir qq chose de pérenne dans le temps un hébergement en interne semble important.
Mettre ces vidéos sur Youtube pose un pb : la musique utilisée est généralement détectée par Youtube qui force la publicité et interdit la vidéo dans certains pays.
J'ai par exemple eu ce pb avec la vidéo d'un pub de 2004 de Bouygues Telecom :
https://www.youtube.com/watch?v=A5BugIQrsY0
-
On ne peut pas écrire un seul octet sur un périphérique "bloc". ;)
Oui c'est vrai. Mais le comportement attendu d'un filesystem si on modifie un octet d'un fichier sans changer sa taille serait (c'est là que l'on entre dans les supputations) de récrire tout le même secteur avec juste l'octet de modifié. C'est d'autant plus utile sur un ssd que dans ce cas le contrôleur peut:
- optimiser l'écriture: écrire en flash = mettre des bits à zéro != effacer = mettre tous les bits de plusieurs pages à 1. Donc si le contrôleur détecte que le(s) octet(s) à modifier ne sont que des bits à mettre à zéro alors il peut récrire sur la même page avec juste les quelques bits de plus à zéro.
- s'il y a le moindre bit à mettre à 1, le contrôleur peut immédiatement marquer la page à effacer sans attendre le trim ou une autre réécriture du secteur, puis réallouer une nouvelle page libre pour l'écriture.
Edit: j'ai oublié qu'il y a des octets de correction d'erreur en plus par page. Donc modifier un octet de donnée à zéro va également modifier le crc et probablement mettre des bits à 1. Donc allocation d'une nouvelle page. Si l'optimisation d'écriture est possible, le cas ou l'utilisation de celle ci doit être tellement rare (faute aux crc) que sûrement pas implanté.
-
J'en profite pour poser une question : comment vérifier que trim est bien actif sur une partition ? (depuis Ubuntu 14.04 Trim est actif par défaut, sauf sur certains SSD blacklisté, mais j'aimerais bien vérifier)
-
J'ai toujours lu que la meilleure méthode était de lancer fstrim périodiquement, idéalement une fois par jour, la nuit.
-
Toutes les jours ou toutes les semaines ?
Sous Ubuntu, c'est mis par défaut une fois par semaine :
/etc/cron.weekly/fstrim avec Ubuntu 14.04 :
#!/bin/sh
# call fstrim-all to trim all mounted file systems which support it
set -e
# This only runs on Intel and Samsung SSDs by default, as some SSDs with faulty
# firmware may encounter data loss problems when running fstrim under high I/O
# load (e. g. https://launchpad.net/bugs/1259829). You can append the
# --no-model-check option here to disable the vendor check and run fstrim on
# all SSD drives.
exec fstrim-all
/etc/cron.weekly/fstrim avec Ubuntu 16.04 LTS et Ubuntu 16.10 :
#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true
-
Moi je le paramètre 1x/jour.
Ca dépend du total d'I/O en écriture je pense. Ce qui est sûr, c'est que personne ne recommande de le faire à la volée.
-
Voici les I/O de LaFibre.info (on note que les reboot le 17 au matin et le 18 a 6h du matin entraînent des IO en lecture alors qu’après c'est dans le cache)
La baisse depuis le 17 novembre à 18h00 est lié au passage de SmokePing sur Ramdsique :
(https://lafibre.info/images/stats/201611_lafibre_diskstats_ssd.png)
-
C'est vraiment intéressant de voir comment tu arrives à optimiser tout ça.
6/ J'envisage de ne plus écrire les données d'un fichier modifié au bout de 30 seconde (la valeur par défaut), mais de 5 minutes. Ainsi la base de donnée, qui est modifiée des dizaines de fois par secondes ne sera plus écrite sur disque que toutes les 5 minutes et non toutes les 30 secondes.
Par rapport à ça, le réglage envisagé s'effectue à quel niveau? Au niveau du système de fichiers? Au niveau de l'application de la base de donnée?
Toutes les modifications ne se font pas "quasi instantanèment" sur le disque dur? J'avoue que ça me surprend...
Leon.
-
Toutes les modifications ne se font pas "quasi instantanèment" sur le disque dur? J'avoue que ça me surprend...
J'ai en moyenne 20 modifications de la base de donnée par seconde pour LaFibre.info avec les commandes insert, update et delete (chaque consultation d'une page met à jour des compteurs par exemple du nombre de vue par exemple)
Si il devait y avoir une écriture systématique, les performances seraient mauvaises avec un disque dur traditionnel.
Le modification de ce paramètre se fait au moment de monter le système de fichier, c'est l'option commit=300 pour 300 secondes = 5 minutes
Par défaut, les données sont écrites sur un disque dur un maximum de 30 secondes. Si tu envoi un fichier de 500 Mo vers une clé USB, tu vois que c'est presque immédiat et que la clé travaille bien après que le transfert soit théoriquement terminé.
commit=secondes
Définir l’intervalle d’écritures périodiques, 30 secondes par défaut. Les plus grandes valeurs décalent la synchronisation des données vers le stockage permanent, avec des conséquences évidentes si le système plante. Aucune limite haute n’est forcée, mais un avertissement est affiché si elle est supérieure à 300 secondes (5 minutes).
Je l'ai mis en place sur mon PC perso (plus pour tester avant de mettre en prod sur LaFibre.info) :
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=3db51002-de26-4ce6-8488-d059e81d5e2a / ext4 commit=300,errors=remount-ro 0 1
# /boot/efi was on /dev/sda2 during installation
UUID=BC6E-E649 /boot/efi vfat umask=0077 0 1
# /home was on /dev/sda7 during installation
UUID=830f10b9-dacd-4f60-a251-6830442099c4 /home ext4 commit=300,defaults 0 2
# swap was on /dev/sda6 during installation
UUID=d0361555-30f9-4791-ad98-e8c6505293c9 none swap sw 0 0
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=4g 0 0
Cela semble pris en compte :
$ dmesg | grep EXT4-fs
[ 1.341136] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[ 1.637965] EXT4-fs (sda5): re-mounted. Opts: commit=300,errors=remount-ro
[ 2.004575] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: commit=300
-
J'en profite pour poser une question : comment vérifier que trim est bien actif sur une partition ? (depuis Ubuntu 14.04 Trim est actif par défaut, sauf sur certains SSD blacklisté, mais j'aimerais bien vérifier)
sudo fstrim -v /
Il dira "xxGB trimmed".
Mais normalement avec un 850 pro aucun soucis, seul le trim asynchrone est blacklisté dans le kernel.
-
Intéressant. Sur un SSD bien rempli (SSD de 1 To rempli a 94%, avec seulement 60 Go de libre)
J'ai :
# fstrim -v /ssd
/ssd: 6,1 GiB (6585294848 bytes) trimmed
trouvant peu d'avoir seulement 6Go de trimmed sur les 60 Go de libre, je lance /sbin/fstrim --all
Et maintenant, j'ai :
# fstrim -v /ssd
/ssd: 0 B (0 bytes) trimmed
Pourquoi ?
-
"fstrim -v /" lance le trim.
Donc si tu le relances, y'a plus rien à faire.
Sous Linux, le Trim ne s'active pas, il se lance.
-
Intéressant. Sur un SSD bien rempli (SSD de 1 To rempli a 94%, avec seulement 60 Go de libre)
J'ai :
# fstrim -v /ssd
/ssd: 6,1 GiB (6585294848 bytes) trimmed
trouvant peu d'avoir seulement 6Go de trimmed sur les 60 Go de libre[/b][/color]
S'il y a des fstrim réguliers, comme sur Ubuntu, alors ce sont 6Go qui ont été effacés depuis la dernière exécution.
Et maintenant, j'ai :
# fstrim -v /ssd
/ssd: 0 B (0 bytes) trimmed
Pourquoi ?
Normal, les 6Go de blocs effacés au niveau filesystem sont maintenant également effacés sur le SSD, pas besoin de renvoyer la commande trim à nouveau.
Tu peux tester :
dd if=/dev/random of=/ssd/testfile bs=1M count=1024 conv=fsync
rm testfile
fstrim -v /ssd
Là tu devrais voir "1GB trimmed".
-
Sous Linux, le Trim ne s'active pas, il se lance.
On peut aussi utiliser l'option de montage discard, qui va lancer la commande trim quand les blocs sont libérés.
Mais ça peut nuire aux performances, à part pour les SSD qui supportent le trim asynchrone (et attention aux bugs...).
https://wiki.archlinux.org/index.php/Solid_State_Drives#Continuous_TRIM
-
Donc sur mon PC perso (jamais allumé la nuit), le fait que j'ai
# fstrim -v /
/: 21,3 GiB (22874333184 bytes) trimmed
# fstrim -v /home
/home: 136,9 GiB (146981949440 bytes) trimmed
Cela signifie qu'il ne s'est jamais lancé (cela dois faire 1mois que j'ai installé ce SSD sur mon PC)
En fait le trim qui se lance dans la crontab une fois par semaine la nuit, c'est bien pour des serveurs, mais pour un PC perso jamais allumé la nuit, c'est pas terrible.
-
En effet, il faut reprogrammer la tache en journée et/ou à une heure où on a l'habitude de s'en servir. Si on la programme 1x/sem, on a toutes les chances de la louper.
On peut aussi utiliser l'option de montage discard, qui va lancer la commande trim quand les blocs sont libérés.
Mais ça peut nuire aux performances, à part pour les SSD qui supportent le trim asynchrone (et attention aux bugs...).
https://wiki.archlinux.org/index.php/Solid_State_Drives#Continuous_TRIM
J'ai découvert cette option assez récemment mais vu que tout le monde la déconseille, je préfère ne même plus en parler.
-
J'ai en moyenne 20 modifications de la base de donnée par seconde pour LaFibre.info avec les commandes insert, update et delete (chaque consultation d'une page met à jour des compteurs par exemple du nombre de vue par exemple)
Tu ne peux pas mettre cette table en RAM et faire des sauvegardes incrèmentales?
Si il devait y avoir une écriture systématique, les performances seraient mauvaises avec un disque dur traditionnel.
Le modification de ce paramètre se fait au moment de monter le système de fichier, c'est l'option commit=300 pour 300 secondes = 5 minutes
Par défaut, les données sont écrites sur un disque dur un maximum de 30 secondes. Si tu envoi un fichier de 500 Mo vers une clé USB, tu vois que c'est presque immédiat et que la clé travaille bien après que le transfert soit théoriquement terminé.
commit=secondes
Définir l’intervalle d’écritures périodiques, 30 secondes par défaut. Les plus grandes valeurs décalent la synchronisation des données vers le stockage permanent, avec des conséquences évidentes si le système plante. Aucune limite haute n’est forcée, mais un avertissement est affiché si elle est supérieure à 300 secondes (5 minutes).
Et si tu utilises un système journalisé pour SSD?
-
Le but est de limiter le nombre d'écritures sur le SSD pour éviter de réduire sa durée de vie.
-
Le nombre de modifications ou bien la quantité de données écrites?
-
Un peu des deux :D
-
J'ai en moyenne 20 modifications de la base de donnée par seconde pour LaFibre.info avec les commandes insert, update et delete (chaque consultation d'une page met à jour des compteurs par exemple du nombre de vue par exemple)
Si il devait y avoir une écriture systématique, les performances seraient mauvaises avec un disque dur traditionnel.
Le modification de ce paramètre se fait au moment de monter le système de fichier, c'est l'option commit=300 pour 300 secondes = 5 minutes
Par défaut, les données sont écrites sur un disque dur un maximum de 30 secondes. Si tu envoi un fichier de 500 Mo vers une clé USB, tu vois que c'est presque immédiat et que la clé travaille bien après que le transfert soit théoriquement terminé.
commit=secondes
Définir l’intervalle d’écritures périodiques, 30 secondes par défaut. Les plus grandes valeurs décalent la synchronisation des données vers le stockage permanent, avec des conséquences évidentes si le système plante. Aucune limite haute n’est forcée, mais un avertissement est affiché si elle est supérieure à 300 secondes (5 minutes).
Je l'ai mis en place sur mon PC perso (plus pour tester avant de mettre en prod sur LaFibre.info) :
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=3db51002-de26-4ce6-8488-d059e81d5e2a / ext4 commit=300,errors=remount-ro 0 1
# /boot/efi was on /dev/sda2 during installation
UUID=BC6E-E649 /boot/efi vfat umask=0077 0 1
# /home was on /dev/sda7 during installation
UUID=830f10b9-dacd-4f60-a251-6830442099c4 /home ext4 commit=300,defaults 0 2
# swap was on /dev/sda6 during installation
UUID=d0361555-30f9-4791-ad98-e8c6505293c9 none swap sw 0 0
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=4g 0 0
C'est mis en place avec le reboot de 6h53 :
$ dmesg | grep EXT4
[ 3.260881] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.945954] EXT4-fs (sda2): re-mounted. Opts: commit=300,errors=remount-ro
[ 4.032655] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: commit=300
-
Le but est de limiter le nombre d'écritures sur le SSD pour éviter de réduire sa durée de vie.
Est-ce qu'il existe des systèmes mixtes combinant SSD et disques?
-
Oui, les SSHD.
-
Oui, je connais, c'est un disque magnétique avec une mémoire aléatoire devant; tu peux faire la même chose avec un simple DD avec une batterie!
Je pensais plus à faire le contraire : un disque magnétique devant un SSD.
-
Et ça serait quoi l'intérêt ?
Quand on met un SSD ou une mémoire alimentée par une batterie devant un disque "mécanique", c'est pour servir de cache : l'écriture est acknowledgé immédiatement au système puis est écrite sur le disque en différé. Cela permet aussi d'avoir un journal d'écriture (avec ZFS par exemple).
Donc faire l'inverse, je vois pas.
Par contre, j'ai déjà vu une RAM sur batterie en face d'un SSD.
-
Justement je voyais plutôt le journal sur le disque mécanique, qui servirait donc de tampon d'écriture assez rapide (en fait c'est la RAM qui servirait de tampon) et si tu fais beaucoup de petites modifications successives sur quelques fichiers, tu uses moins le SSD.
Mais à la réflexion il vaut mieux avoir un gros disque mécanique pour la grande capacité, un SSD pour la vitesse de lecture de petits fragments de données (mais pas les gros fichier séquentiels!), et un petit disque mécanique pour écrire le journal.
-
C'est assez tordu ce que tu nous proposes : en général on met juste un SSD en cache d'un gros disque dur pour la capacité. Pour l'endurance, comme la limite d'un SSD de bonne qualité est quand même très élevée, ce n'est pas tellement un problème de beaucoup écrire dessus, d'autant plus si celui-ci ne fait que office de cache derrière un disque dur. (sauf si on est maniaque, ou très précautionneux comme vivien)
-
C'est pour profiter du débit d'écriture séquentiel du disque, qui peut être de l'ordre de 150 Mo/s; cela génère donc des commit rapides.
D'un autre coté, si il y a de nombreuses données en attente sur ce disque, en cas de crash il faudra commencer par tout relire pour accéder au système de fichier.
C'est juste des idées comme ça, je n'ai pas étudié les détails.
-
Quand on veut faire du séquentiel à haut débit, rien ne vaut un SSD quand même, je fais 1,2Go/s en écriture sur mon laptop.
-
Tu arrives à produire 1,2 Go/s?
-
Moi non, en dehors des outils de benchmarking. mais ceux qui en ont l'utilité doivent savoir. (En vidéo notamment)
-
Attention. L'écriture sur la flash est plutôt lente comparer à la lecture. Elle peut même être plus lente qu'écrire sur le disque (via la ram en tampon). Surtout s'il faut effacer un secteur avant d'écrire. Mon avis sur les sshd c'est que la flash sert surtout comme cache pour les secteurs souvents accédés en lecture par le système, et que l'écriture n'est pas accéléré (à part comme d'habitude par la ram du contrôleur).
-
Attention, la principale qualité d'un SSD c'est son temps de réponse, pas forcèment son débit !
Un petit SSD de 32 ou 64Go n'écrira qu'à 50Mo/s par contre son temps de réponse est d'environ 0,01 ms contre 6ms sur 15000rpm, 7,5ms sur un 10000rpm et 15ms un 7200rpm.
On parle de plusieurs dizaines de milliers d'iops pour un SSD contre une centaine pour un disque dur (150 iops un 15000rpm, la moitié pour un 7200rpm).
-
Ok pour le temps d'accès. Mais l'effacement d'un secteur prend aussi un temps comparable voir supérieur au temps d'accès d'un dd. Du coup utiliser la flash en cache d'écriture est vraiment une mauvaise idée. Par contre pouvoir accéder sans latence aux secteurs souvents accédés en lecture c'est là ou se situe l'avantage de la solution.
-
Euh faut que tu te mettes à jour : mettre un SSD en cache est la technique la plus utilisée en ce moment pour accélérer les temps de réponse.
ZFS est spécialement prévu pour ce use-case : ZIL. J'utilise un SSD en frontal de mes disques, les iops en écriture sont incomparables. On parle de milliers d'iops contre une centaine.
Proof (blocs de 4k sur fichier de 10m, écriture en mode SYNC)
# iozone -R -z -t 1 -r 4k -s10m -O -F test -o
...
Children see throughput for 1 initial writers = 6237.24 ops/sec
...
La même sur un 15000rpm:
Children see throughput for 1 initial writers = 53.12 ops/sec
-
Moi non, en dehors des outils de benchmarking. mais ceux qui en ont l'utilité doivent savoir. (En vidéo notamment)
Tu fais de la vidéo à 1 Go/s? Dans quel contexte?
Tu as provisionné un disque de 10 To pour monter ton film? C'est pas un peu overkill?
-
Donc personne ne fait de la vidéo à 1 Go/s?
-
Si, demandes à Mattmatt le débit d'un flux 1080p en RAW, de mémoire on s'approche du Go/s. Certains traitent ça en brut sur leurs workstations (avec des solutions type blackmagic)
-
Tu t'amuses comme tu veux, mais moi je ne vois pas l'intérêt par rapport à un RAID.
-
De mémoire, c'est un RAID 0 interne dans tous les SSD modernes
-
Si, demandes à Mattmatt le débit d'un flux 1080p en RAW, de mémoire on s'approche du Go/s. Certains traitent ça en brut sur leurs workstations (avec des solutions type blackmagic)
1080*1920 progressif 50 images/s, environ 3Gb/s
on enregistre sur ça par exemple : http://pro.sony.com/bbsc/ssr/cat-srmemory/cat-memory/product-SR1TS55/
au alentour de 8000$ la cartouche, c'est des raids de SSD
-
Garantir presque 6Gb/s en écriture c'est pas mal du tout. Mais on est loin des 1,2Go/s de Hugues ;)
-
Suffit de faire du 2160p en 10 bit par exemple, ensuite si tu veux pousser le vice, tu fais du 60fps, et tu les tapes.
-
Euh faut que tu te mettes à jour : mettre un SSD en cache est la technique la plus utilisée en ce moment pour accélérer les temps de réponse.
ZFS est spécialement prévu pour ce use-case : ZIL. J'utilise un SSD en frontal de mes disques, les iops en écriture sont incomparables. On parle de milliers d'iops contre une centaine.
Proof (blocs de 4k sur fichier de 10m, écriture en mode SYNC)
# iozone -R -z -t 1 -r 4k -s10m -O -F test -o
...
Children see throughput for 1 initial writers = 6237.24 ops/sec
...
La même sur un 15000rpm:
Children see throughput for 1 initial writers = 53.12 ops/sec
Sur ce point, t'as raison. Avec un SSD assez gros devant normalement remplacer un disque dur, et le bon algorithme pour gérer l'écriture en tampon à travers, ça passe très bien.
D'ailleurs je crois que windows intègre ce genre de fonctionnalité, et là à priori tu me montres un linux. Ça m'intéresse de savoir comment ça marche et comment t'as fais sous linux :D
Par contre, dans mon message je pensais plus à ça: https://www.grosbill.com/4-seagate_desktop_sshd_1_to_8_go_ssd_-600147-informatique-_disque_dur
Avec seulement 8Go, difficile de faire du wear leveling correct (étalement de nombre d’écriture par secteur), surtout si la flash sert en tampon pour l'écriture. Donc à mon avis la flash ne sert pas en écriture ou très peu.
-
Suffit de faire du 2160p en 10 bit par exemple, ensuite si tu veux pousser le vice, tu fais du 60fps, et tu les tapes.
mais non monsieur, UHD en 10 bit HDR et 120 fps comme le conseillent BBC et EBU , c'est un peut moins de 24Gb/s
https://kws.smpte.org/kws/public/projects/project/details?project_id=180
http://www.c-dis.net/embrionix.html
-
çà fait 3Go/s, j'ai gagné ;D
-
Par contre, dans mon message je pensais plus à ça: https://www.grosbill.com/4-seagate_desktop_sshd_1_to_8_go_ssd_-600147-informatique-_disque_dur
Avec seulement 8Go, difficile de faire du wear leveling correct (étalement de nombre d’écriture par secteur), surtout si la flash sert en tampon pour l'écriture. Donc à mon avis la flash ne sert pas en écriture ou très peu.
Je ne sais pas comment est utilisé la flash sur ce type de disque par rapport à un SSD en ZIL. C'est pas tellement la capacité qui me gêne mais plus la manière de s'en servir. Le SSD que j'utilise en ZIL fait 64Go mais seulement 8Go sont utilisés. Ca suffit pour accélérer toutes les opérations disques des VM en NFS (lecture/écriture aléatoire) par contre, dès qu'on copie des gros fichiers, ça devient un bottleneck : le débit séquentiel des disques est supérieur au débit en écriture du SSD. Note: le ZIL apporte une sécurité sur les écritures en cas de crash puisque ça fait office de journal.
Comme j'ai 16Go de RAM sur le NAS, je n'ai pas mis de cache en lecture (L2ARC) sur le SSD, l'efficacité par rapport au volume de données accédé aurait été faible (le cache en RAM suffit). Donc là, même punition.
-
Note: le ZIL apporte une sécurité sur les écritures en cas de crash puisque ça fait office de journal.
Le ZIL n'est utilisé que pour les applications nécessitant des écritures synchrones (O_DSYNC : écriture commitée = écriture garantie), il va servir de garantie d'intégrité pour les données (et pas seulement les meta-données comme sur un filesystem journalisé standard).
Cas d'usage typiques : NFS et SGBD.
Le cas d'usage de la vidéo est inapproprié à ZIL car les écritures sont bufferisés et sans la contrainte d'être synchrones : dans ce cas le ZIL ne sera pas utilisé et le cache RAM sera de toutes façons plus performant que le ZIL et suffisant en terme d'intégrité puisque le journal du filesystem assurera l'intégrité des métadonnées (peu importe le rollback d'une écriture sur ce type d'application).
-
C'est mis en place avec le reboot de 6h53 :
$ dmesg | grep EXT4
[ 3.260881] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.945954] EXT4-fs (sda2): re-mounted. Opts: commit=300,errors=remount-ro
[ 4.032655] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: commit=300
L'option commit=300 secondes (valeur par défaut = 30 secondes) ne diminue que peu les écritures sur le SSD, toutefois son action ne semple pas nul
La mise en place de l'option est réalisée le 24 au matin, là où il y a un pic important en lecture, lié au fait que le cache de lecture en ram a été vidé :
(https://lafibre.info/images/stats/201611_diskstats_iops_apres_optim.png)
Au total, si on regarde avant la mise de SmokePing dans un Ram disque persistant, j'ai presque divisé par deux les écritures sur le SSD :
(https://lafibre.info/images/stats/201611_lafibre_diskstats_ssd.png)
-
291 jours que le SSD est installé sur le serveur LaFibre.info
Aujourd'hui j'ai
- Wear_Leveling_Count = 10
Wear Leveling Count : Représente le nombre d’opérations moyenne d’effacement effectué sur le support (le nombre de fois qu’un bloc a été effacé). C'est une moyenne sur le nomre total de blocs du SSD et non un maximum.
- Total_LBAs_Written = 3784689601
Total LBAs Written (attribut SMART 241) : Représente la taille totale des blocs LBA (Logical Block Addressing) requis pour traiter l’ensemble des demandes d’écriture envoyées au SSD depuis l’hôte. Pour calculer la taille totale (en octets), il faut multiplier la valeur remontée par SMART par 512.
3784689601*512/1000000000 = 1937,761 Go écrit depuis 291 jours, soit 6,659 Go par jour. Je suis loin de la limite pour la garantie : Le SSD est garanti pour 150 To écrit ou 10ans. 150 To sur 10 ans = 150000 Go sur 3652 jours = 41,068 Go par jour
# smartctl -a /dev/sda
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.10.0-32-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 850 PRO 512GB
Serial Number: S39FNWAH978067B
LU WWN Device Id: 5 002538 d703ab405
Firmware Version: EXM02B6Q
User Capacity: 512 110 190 592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Fri Aug 25 17:35:35 2017 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 265) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 6990
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 4
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 10
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 073 057 000 Old_age Always - 27
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 100 100 000 Old_age Always - 0
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 3784689601
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
255 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
-
817 jours (2 ans et presque 3 mois) que le SSD est installé sur le serveur LaFibre.info
Aujourd'hui j'ai
- Wear_Leveling_Count = 25
Wear Leveling Count : Représente le nombre d’opérations moyenne d’effacement effectué sur le support (le nombre de fois qu’un bloc a été effacé). C'est une moyenne sur le nomre total de blocs du SSD et non un maximum.
- Total_LBAs_Written = 10047430477
Total LBAs Written (attribut SMART 241) : Représente la taille totale des blocs LBA (Logical Block Addressing) requis pour traiter l’ensemble des demandes d’écriture envoyées au SSD depuis l’hôte. Pour calculer la taille totale (en octets), il faut multiplier la valeur remontée par SMART par 512.
10047430477*512/1000000000 = 5144,284 Go écrit depuis 817 jours, soit 6,297 Go par jour. Je suis loin de la limite pour la garantie : Le SSD est garanti pour 150 To écrit ou 10ans. 150 To sur 10 ans = 150000 Go sur 3652 jours = 41,068 Go par jour
# smartctl -a /dev/sda
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.15.0-43-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 850 PRO 512GB
Serial Number: S39FNWAH978067B
LU WWN Device Id: 5 002538 d703ab405
Firmware Version: EXM02B6Q
User Capacity: 512 110 190 592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Feb 2 09:19:08 2019 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 265) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 19606
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 7
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 25
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 074 055 000 Old_age Always - 26
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 3
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 10047430477
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
255 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
-
De nouvelles stats pour ses quatres ans et demi vivien ? :)
-
Voila :
1631 jours (4 ans et demi) que le SSD est installé sur le serveur LaFibre.info
Aujourd'hui j'ai
- Wear_Leveling_Count = 51
Wear Leveling Count : Représente le nombre d’opérations moyenne d’effacement effectué sur le support (le nombre de fois qu’un bloc a été effacé). C'est une moyenne sur le nomre total de blocs du SSD et non un maximum.
- Total_LBAs_Written = 21282572872
Total LBAs Written (attribut SMART 241) : Représente la taille totale des blocs LBA (Logical Block Addressing) requis pour traiter l’ensemble des demandes d’écriture envoyées au SSD depuis l’hôte. Pour calculer la taille totale (en octets), il faut multiplier la valeur remontée par SMART par 512.
21282572872*512/1000000000 = 10896,7 Go écrit depuis 1631 jours, soit 6,681 Go par jour. Je suis loin de la limite pour la garantie : Le SSD est garanti pour 150 To écrit ou 10ans. 150 To sur 10 ans = 150000 Go sur 3652 jours = 41,068 Go par jour.
# smartctl -a /dev/sda
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.15.0-140-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 850 PRO 512GB
Serial Number: S39FNWAH978067B
LU WWN Device Id: 5 002538 d703ab405
Firmware Version: EXM02B6Q
User Capacity: 512 110 190 592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Mon Apr 26 08:56:53 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 265) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 39140
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 8
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 51
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 072 055 000 Old_age Always - 28
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 4
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 21282572872
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
255 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
-
Petite mise à jour :
2068 jours (5 ans et 8 mois) que le SSD est installé sur le serveur LaFibre.info
Aujourd'hui j'ai
- Wear_Leveling_Count = 81
Wear Leveling Count : Représente le nombre d’opérations moyenne d’effacement effectué sur le support (le nombre de fois qu’un bloc a été effacé). C'est une moyenne sur le nomre total de blocs du SSD et non un maximum.
- Total_LBAs_Written = 30149638521
Total LBAs Written (attribut SMART 241) : Représente la taille totale des blocs LBA (Logical Block Addressing) requis pour traiter l’ensemble des demandes d’écriture envoyées au SSD depuis l’hôte. Pour calculer la taille totale (en octets), il faut multiplier la valeur remontée par SMART par 512.
30149638521*512/1000000000 = 15436,6 Go écrit depuis 2068 jours, soit 7,465 Go par jour. Je suis loin de la limite pour la garantie : Le SSD est garanti pour 150 To écrit ou 10 ans. 150 To sur 10 ans = 150000 Go sur 3652 jours = 41,068 Go par jour.
# smartctl -a /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.13.0-52-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 850 PRO 512GB
Serial Number: S39FNWAH978067B
LU WWN Device Id: 5 002538 d703ab405
Firmware Version: EXM02B6Q
User Capacity: 512 110 190 592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Jul 7 20:01:57 2022 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 265) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 49639
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 8
177 Wear_Leveling_Count 0x0013 098 098 000 Pre-fail Always - 81
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 073 055 000 Old_age Always - 27
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 4
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 30149638521
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
255 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
-
Petite MAJ ? après le incident sur DC?
-
Petite question... Pourquoi ne pas avoir acheté un autre SSD pour faire du RAID 1 par exemple ?!
-
sacré SSD il en a vu ;D
j'ai toujours mon Samsung 830 256Go de 2012 moi ;D bon il a pas du autant travailler ;D
-
Pour insignifiants qu'ils soient, tous mes encouragements à ADELI/MAXNOD pour une reprise et la continuité de leurs opérations.
Petite question... Pourquoi ne pas avoir acheté un autre SSD pour faire du RAID 1 par exemple ?!
Un raid améliore la disponibilité.
Même si dans le cas présent vous augmentez vos chances, ce n'est pas une stratégie de reprise après sinistre.
Quand bien même côté matériel c'est, ici, faire avec ce qui est disponible (plutôt que ce qui a été prévu pour), le fait même que vous puissiez utiliser ce forum sous x heures montre que ce qui importe le plus a été effectué (une sauvegarde externe de l'état du système et de ses données). L'utilisation d'un matériel encore viable voire de données localement préservées est un bonus temporel mais pas une stratégie.
-
Le RAID peut dégrader aussi la situation.
Ici, j'aurais eu une carte RAID Hardware, il est probable que cela aurait été plus compliqué, les disques peuvent n'être lisibles que via la carte RAID qui les a formatés (et pas une autre).
Quand la carte RAID tombe en panne, cela peut être complexe pour récupérer les données si on n'a pas un autre serveur avec la même carte RAID sous la main.
Petite mise à jour :
2333 jours (6 ans et 5 mois) que le SSD est installé sur le serveur LaFibre.info
Aujourd'hui j'ai
- Wear_Leveling_Count = 92
Wear Leveling Count : Représente le nombre d’opérations moyenne d’effacement effectué sur le support (le nombre de fois qu’un bloc a été effacé). C'est une moyenne sur le nombre total de blocs du SSD et non un maximum.
- Total_LBAs_Written = 35153257429
Total LBAs Written (attribut SMART 241) : Représente la taille totale des blocs LBA (Logical Block Addressing) requis pour traiter l’ensemble des demandes d’écriture envoyées au SSD depuis l’hôte. Pour calculer la taille totale (en octets), il faut multiplier la valeur remontée par SMART par 512.
35153257429*512/1000000000 = 17998,4 Go écrit depuis 2333 jours, soit 7,714 Go par jour. Je suis loin de la limite pour la garantie : Le SSD est garanti pour 150 To écrit ou 10 ans. 150 To sur 10 ans = 150000 Go sur 3652 jours = 41,068 Go par jour.
# sudo smartctl -a /dev/sda
[sudo] Mot de passe de vgu :
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.15.0-69-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 850 PRO 512GB
Serial Number: S39FNWAH978067B
LU WWN Device Id: 5 002538 d703ab405
Firmware Version: EXM02B6Q
User Capacity: 512 110 190 592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Wed Mar 29 20:17:43 2023 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 265) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 088 088 000 Old_age Always - 55987
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 12
177 Wear_Leveling_Count 0x0013 098 098 000 Pre-fail Always - 92
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 075 055 000 Old_age Always - 25
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 8
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 35153257429
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
255 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
-
Tu vas peut-être demander un nouveau disque au Père Noël.
Remarque, j'en ai un petit qui me dit :
$ sudo smartctl -a /dev/sdb|grep -iE "failing|model"
Model Family: Samsung based SSDs
Device Model: SAMSUNG MZMPC032HBCD-000H1
173 Wear_Leveling_Count 0x0013 014 014 017 Pre-fail Always FAILING_NOW 3126
Je ne sais pas combien de temps ça va durer.
-
6 ans et demi, il a à peine fini le rodage ! ;D
17To écris, je sais même pas si j'ai pas autant sur mes SSD perso, je vais vérifier ;D