Reprise du message précédent :
Ajout d'un Samsung 840 Pro dans la liste des owners

bah pour ma part, je ne sais pas comment accéder à ces cellules de réserve... si tant est qu'elles soient accessibles... il faudrait aussi qu'elles soient exploitables... et puis elles servent à quoi ? (j'en ignorais même l'existence)

Il me semble que le secure-erase met tout à 0, sans distinction.
 
Les cellules de réserve servent principalement au wear-levelling (voir FP).

ok, mais sont-elles pour autant exploitables ?

Je ne pense pas que le secure erase met tout à 0. Puis que ces cellules sont par définition non accessibles. non?

Pour moi le SSD est une boite noir qui nous montre Xgo. Il se trouve que physiquement il peut aussi y en avoir 8/16 go pour l'overprovising ou pour contrer le pb de puce défectueuse, mais on ne sait pas ou est stockée l'information, ça c'est le contrôleur qui se démerde, du coup je ne suis vraiment pas sûr que tout soit formatable.

Je me trompe?

De ce que j'ai compris du fonctionnement des SSD (et encore, c'est peut être pas le cas pour tous les SSD), le wear-levelling se sert des cellules en ordre plus ou moins séquentiel pour les utiliser au maximum et ainsi gérer l'usure du SSD de manière la plus uniforme possible.
Dur de dire si le SSD fait également tourner les cellules dédiées à l'overprovising pour que celles-ci soient aussi prises en compte dans le processus de gestion de l'usure. Toujours est-il qu'un secure erase est censé remettre toutes les cellules utilisées à 0, j'imagine donc que lors de l'effacement, le contrôleur sait quelles cellules il doit effacer pour remettre le SSD en config usine.
Et dans tous les cas, on a pas de contrôle là dessus, le contrôleur gère tout seul, et je fait confiance aux fabriquant pour gérer ça correctement en hard ou via le firmware. Au pire, si quelques cellules restent non effacées, la probabilité qu'elles contiennent des infos sensibles exploitables est extrêmement faible et peut donc être ignorée.

Ce soir je passe ma config principale sous ubuntu.

Sous windows (patapay) j'avais un driver ahci.
J'ai donc activé le mod ahci dans le bios.

Que dois-je faire ?

Coucou,
tu as regardé par ici si tu trouvais des infos : http://doc.ubuntu-fr.org/ncq_native_command_queuing ?
je ne peux malheureusement pas t'aider plus, j'ai pas eu à faire avec cette question encore.

Rien

Vous utilisez quoi pour les bench ?
C'est pour comparer avec windows.

C clair que 1Go pour du /boot .... vous mettez tout vos modules dans votre "kernel" ou quoi ?   (et encore ...)
 
Sur un Samsung 840 250Go moi j'ai fait :
- /boot de 200Mo en ext2 (inutile de journaliser quelques fichiers, partition alignée)
- / de 220 Go en ext4 (partition alignée en  Mo, à l'installation de la linux mint lmde cinnamon)
- une swap de 16 Go (j'ai 16Go de ram ddr3, partition alignée)
 
Par contre j'ai pas joué avec le fstab ou le /tmp : je me rappelle plus l'interêt pour SSD.
 
ce qui devient bluffant c'est le temps de boot : entre le moment ou je presse "enter" sous grub et la mire de connexion GDM ... maxi 4 à 5 sec.
On ne voit même plus l'init et le system v ...  

Vous pouvez m'ajouter dans le recensement :

Vertex 4 128Go Ubuntu à jour (12.10)

c'était pour un raid0 donc avec 2 disques  

Salut les gars, j'ai une petite question. Le HDD de mon portable du boulot a lâché, et j'ai récupéré un autre HDD qui intègre un petit cache SSD (2 Go je crois). Est-ce que ce cache sera utilisé par ma distrib Linux sans que je fasse quoi que ce soit, ou bien il y a des manips à faire ?

C'est quel modèle de HDD ?

http://www.materiel.net/disque-dur [...] 58183.html
 
Je crois que c'est ce modèle là. En tout cas, c'est un Seagate Momentus 500Go avec un peu de cache SSD, donc si c'est pas ce modèle-là, ça y ressemble fortement.

Il me semble que les Momentus sont indépendant de l'OS ou du système de fichiers, donc tu devrais pouvoir profiter du cache SSD sous Linux sans souci. A vérifier.
 
Par contre, quand je cherche à voir comment ce modèle se comporte avec ext3 ou 4, les premiers liens Google font état de corruption de données J'ai pas lu le contenu des articles, je te laisse regarder, mais la vigilance semble être de mise.

Okay merci, je vais regarder ça.

je viens d'avoir un freeze sur mon SSD (Corsair Force GT 120 Go)
vu que dans mon partitionnement mon /var/log est sur le HDD j'ai une trace du freeze:

 
après reset tout a l'air d'être dans l'ordre et de marcher correctement mais ça me semble inquiétant ce crash. Je crois que je vais faire quelques backups    
 
tout est nickel aussi au niveau du S.M.A.R.T, ça ressemble plus à un plantage du lien qu'à une vrai défaillance hard du SSD
 
j'ai eu chaud  

Coupure de courant ?

non aucune coupure, un plantage
 
 
sinon intéressant:
 
un cache SSD pour linux: http://www.phoronix.com/scan.php?p [...] px=MTI3NDg
 
lexique rapide:
write-back: cache en lecture et écriture
write-through: cache en lecture uniquement, les écriture sont faites directement sur le disque dur(ou en parallèle avec le SSD), même si le SSD merde il n'y a pas de perte de données

Hop, un Intel 520 120Go tout chaud chez moi

Monté sur mon Thinkpad X200, partitionné en GPT (donc aligné) :
-2Mo "BIOS Boot partition"
-16Go Ext4 pour /
-2Go swap
-94Go Ext4 pour /home

Partitions montées en noatime et discard.

Pas chronométré mais le boot de Archlinux doit prendre 3s

question naive, pourquoi tu as du swap sur un ssd ?

Au cas où je sois limite en RAM (j'ai 4 Go de ram sur ce portable, si je lance 2 VMs ça peut commencer à être limite), je préfère que ça swappe un peu plutôt que l'OOM-killer entre en action et me défonce mon travail en cours
 
Et je ne suis pas un paranoïaque des cycles d'écriture, avoir du swap sur le SSD ne m'empêche pas de dormir la nuit    
 
Je passerai peut-être le swappiness à 0 pour qu'il n'entre en action qu'en cas de réel besoin, mais pour l'instant je ne l'ai pas encore vu être utilisé.

WM?

 
En gros ça doit faire ~2-3s Grub -> Slim, et 1s de chargement de XFCE.

Tite question:
 
ca donne quoi la gestion du TRIM sur du raid logiciel?

Je dirais que ça dépende du support du RAID par la méthode de RAID logiciel utilisée. Mais ce n'est qu'une intuition, je connais très peu le domaine.

d'après ce que je viens de lire, le trim serait en passe d'être supporté pour le raid 1/0/10 avec mdadm
 
dixit https://lkml.org/lkml/2012/3/11/261

iozone avec les options suivantes donne des résultats qu'on peut comparer avec HDTach (le soft utilisé sur tous pleins de benchs sous windows, suis pas sûr du nom)

Note : inutile d'activer le cache cpu dans ce cas (-S <KB> ) en tous cas il m'a ralenti un peu sur ce test.
 
il t'affiche rapidement les résultats (en KB ce qui fait un peu iech, faut diviser par 1024)
exemple :

héhé c'est toujours la classe sur un portable, genre le keum à côté avec son portable @2000€ sous un autre OS assez connu, qui *était* tout content des 25" pour démarrer à froid    
Tu as réglé le I/O scheduler ?
 
Ici avec une nouvelle config @300€ : Core i3 / SSD SanDisk Extreme 120G + HDD Hitachi SataII / DDR3 2x2GO / Arch Linux (lvm, kernel-ck, deadline I/O scheduler, boot UEFI) :

Yaisse, bientôt dispo inchalla    
Je suis aussi (en Fr) : Matériel : Accéleration disques durs via SSD sous Linux : les technos existantes (10/2012), et « a Pure software implementation » SSD, LVM, Tiered storage - speeding up your storage - alpha version! » (sur le bbs Arch English)
 

yaisse cool. Aussi pour bientôt (en cours ?) pour les partitions encryptés LUKS j'ai lu (sur des blogs ou le bbs Arch de mémoire jsais plus, pas de pc portable avec ssd)
et vu que lvm2 gère déja le TRIM, ba-bye les partitions en dur (que c'est la misère à changer)    
 
À propos me suis creusé la tête avant de formater (tain, quelles options passer à mkfs.EXT4 ?).
Pour rien. les "custom stride" et "-b 4096"... ralentissent les performances, comme le montre Rene Mayrhofer's sur son très complet SSD Linux benchmarking: Comparing filesystems and encryption methods  
À propos on teste pas mal de marques et modèles de SSD sous Arch Linux avec un protocole de test standardisé : SSD Benchmarking
Corsair, Crucial, Intel, OCZ, Samsung, Sandisk, Kingston, Mushkin et Liteon pour le moment. Partitionnement standard / lvm2 / Encrypted Partitions (dm-crypt with AES et Truecrypt) + Comparaison avec high end SCSI RAID 0 hard drive benchmark

hello, je peux vous demander de l'aide ?
 
J'ai un Corsair Force Series F120 sur mon probook 4330s, je viens de faire une install de Wheezy en lvm avec chiffrement aes-cbc-essiv:sha256.
 
J'ai créé avec gparted ma première partition /boot aligné correctement il me semble :
 

 
J'ai ensuite créé sur /dev/sda2 un volume chiffré et par dessus lvm.
J'ai ajouté noatime et discard à /etc/fstab sur mon lv / .
 
Y a t il certaines précautions pour avoir de bonnes perfs ? C'est pas top ce que j'ai fais ?  

Surtout que mon X200 m'a couté 100€ en état nickel, et donc la même chose en plus pour y ajouter le SSD  
De la bonne machine de compét (pour mon utilisation) à pas cher.

Je n'avais pas encore réglé le IO scheduler, je viens de passer à noop pour voir.

Pour mon temps de boot, je viens de regarder le graphique systemd-analyze, le temps de boot total pour arriver sur Slim est de 2s, j'estime à 1s de plus le chargement de mon bureau XFCE après login.
Le temps donné par systemd-analyze pour userspace n'est pas réaliste dans mon cas, il attend que le service client OpenVPN soit lancé et connecté, ce qui n'est le cas qu'une fois le Wi-Fi connecté sous mon bureau.

Quelqu'un peut me rappeler la commande (ou l'endroit) pour obtenir les résultats du temps du boot (kernel + initrd + userspace =... ) SVP ? Merci !

deK semble parler de systemd-analyse, c'est peut être ça. Je me rappelle avoir utilisé autre chose il y a quelques temps, mais je n'arrive pas à me rappeler du nom... Peut être bootchart ?

Oui, c'est ça, "systemd-analyse" pour avoir le temps de boot, et "systemd-analyse blame" pour voir ce qui met le plus de temps
 
Edit : peut-être à mettre ne première page ?

Je pense qu'au cas où, il faudrait faire un paragraphe plus général avec les différents outils de mesure du temps de boot, parce que systemd-analyse, c'est bien, quand on démarre avec systemd (Lapalisse, bonsoir). Or de nombreuses distrib ne sont pas passées à sustemd et ne l'envisage pas (Debian en tête si j'ai bien suivi). Du coup, je préférerais faire quelque chose de plus complet.
Si quelqu'un veut m'y aider... Reste que l'idée me semble intéressante.

ils maintienent une page assez complete pour faire tourner systemd sous debian:
http://wiki.debian.org/systemd
 
après j'ai jamais testé si ça tournait vraiment  

je me pose la question du RAID de SSD pour un serveur:
point important: il n'y aura pas de données sensibles stockées sur le SSD (serveur de calcul)
 
du coup je me demande si ça ne serait pas plus judicieux de faire du RAID0 (divisant par 2 au passage le nombre d'écriture par disque et donc la durée de vie) plutôt que de faire du RAID1 (redondance, pas mal si un des SSD merde tout seul)
 
(ou carrément ne pas faire de RAID du tout )

salut les gens
 
j'ai un ssd sur XBMCBuntu ( frodo 12RC2, donc assez récente )( petit pc mediacenter dont le détail est dans ma conf ) et un autre sur un pc à tout faire avec la derniere release de Centos installée ( pour l'instant, j'me tate pour changer de distro ).
 
y'a un truc particulier a faire pour avoir un ssd performant et sain ou tout se fait bien tout seul par défaut avec les dernieres distros ?
 

Merci à tous les 2.

 
 
Un OCZ Vertex 2 ici qui tourne sous Debian Wheezy de la sorte  
 
/dev/disk/by-uuid/77b707c3-3dcd-4259-9d75-e3f15f046940 ext4       331M  154M  160M  50% /
tmpfs                                                  tmpfs      5,0M     0  5,0M   0% /run/lock
tmpfs                                                  tmpfs      404M  192K  403M   1% /run/shm
/dev/sda8                                              ext4        44G   13G   29G  31% /home
/dev/sda7                                              ext2       447M   65K  423M   1% /tmp
/dev/sda5                                              ext4       8,4G  3,5G  4,5G  44% /usr
/dev/sda6                                              ext4       2,8G  867M  1,8G  33% /var
 
C'est tout bon or not tout bon ?  
 
Merci !