Reprise du message précédent :
Bonjour.
 
Merci pour vos lumières et le lien.
 
Mais ce que je ne comprends pas, ce n'est pas tant l'option en elle même, mais plutôt ce qu'elle fait dans le résultat du mount, alors que je ne la passe pas dans le fstab.
 
C'est-à-dire qu'un noatime ou un discard, implique que le système monte obligatoirement les partitions avec user_xattr ?
 
 
 

Hello, il y a un tas d'options que tu ne précises pas dans /etc/fstab et qui sont pourtant utilisées : par défaut...
 
Et donc user_xattr est une option de montage par défaut. En quoi te pose-t-elle un problème?

hop ! Je viens de tomber ici en cherchant "SSD Linux" sur Google .. Et étant familier du forum, je dépose mon    
 
Je viens d'acheter un SSD Crucial M500 240Go (+ nouvelle config entre autre..) et attend la prochaine Kubuntu 14.04 pour tout y mettre.. sachant que je suis sous KDE depuis 14 ans
 
 

Ah là là, ton avatar    WhiteLightning, X-Copy, RattleCopy... souvenirs, souvenirs
À méditer

Pas de problèmes de mon côté sur des Samsung EVO en 500 et 750

au final, ça serait quand même étrange que cette feature soit mal implémentée dans 2 contrôleurs différents, ou alors les développeurs kernel devraient douter de leur propre utilisation de cette feature. Ce qui n'a pas l'air d'être le cas vu qu'ils ont juste blacklisté le M500...

Je viens d'acheter un m500 240Go pour mon laptop de taf (sous Suze).
Même pas peur

Un peu plus de précision ?  

ils ont blacklisté le M500 pour la fonctionnalité "queued trim", qui permet de programmer un trim sans bloquer le disque.
Contrairement au trim classique synchrone qui bloque le disque jusqu'à ce que le trim soit terminé.
 
Le queued trim est buggué sur M500... donc il font en sorte de ne pas l'utiliser sur ce disque par blacklisting

haaa ok... je vais me renseigner merci

 tu as probablement raison.
 
J'avais loupé ça:
http://comments.gmane.org/gmane.linux.ide/56084

Donc on peut supposer que Crucial va bientôt corriger le bug...
 
En attendant le nouveau firmware, je pense qu'il est sage de désactiver le discard sur les fs et le swap dans /etc/fstab pour les M500, quelque soit la version kernel, et de faire périodiquement les trim manuellement ou via cron ("swapoff -a && swapon --discard=once -a" pour le swap). Même si le risque de tomber sur un kernel qui ne blackliste pas le M500 (de 3.12 à 3.13.7 en stable) est faible...

Sinon le risque c'est quoi ?

grosses corruptions du système de fichier (voire carrément partition inutilisable)

arff ok... :\

le risque est seulement présent entre 3.12 et 3.13.7, si tu n'utilise une version du kernel dans cette plage c'est bon

bhaa mon M500 est en attente de Kubuntu 14.04 (Kernel 3.13.5 ou ptet 3.14 d'apres Canonical)  je compte pas le monter avant... ou alors si.. si je perd patience

En fait, il y a moyen de vérifier si un kernel >= 3.12 blackliste ton modèle de M500 (les grosses distribs patchent souvent leur kernel "stable" avec les correctifs du mainstream) :

Firmware Update MU05 pour Crucial M500 !!! yippeee !!!
 

 
http://www.crucial.com/support/firmware.aspx

Certes mais est-ce qu'il corrige le fameux bug rapporté ici ? :-)

j'attendais justement que kkun nous fournissent l'info

Hello,

J'ai rapidement parcouru les dernières pages. Je viens d'acheter un nouveau laptop sous Debian Sid équipé d'un noyau 3.13.1 équipé d'un Crucial M500.

Pensez vous que je doive placer le no discard et noatime dans le fstab ? J'ai pas trop compris l'histoire de blacklist du m500.

Merci pour votre aide.

Bonne nouvelle    
 
poussez-pas derrière pour l'update    
 
OK je vais tester, ça me parait prometteur :

• Corrected Upgrade issues experienced on MU03 by some customers
• Numerous Bug fixes and stability improvements

bientôt RIP mon pauvre M500    
 
 

Les infos sont les mêmes dans le guide.  
Bravo le changelog Crucial

De mon côté j'hésites à changer mon ssd 520 intel pour un samsung 840pro, non pas que je sois mécontent de mon 520, il me satisfait parfaitement (aucun soucis avec etc), juste que 256go ça commence à faire short avec les vm.

Dans le doute, il vaut mieux effectivement ne pas mettre discard dans /etc/fstab (le noatime sans problème)
 
Donc, upgrade MU05 fait pour le M500 (sans problème) :

Par contre j'hésite un peu à remettre le discard sur un kernel 3.13.6 (sans blacklist)
 
PS: j'ai oublié de signaler une dégradation des perfs du M500 avec le firm MU05; rien de grave, ~10Mo/s sur crystal mark pour les écritures... Je préfère un ssd sécurisé à un ssd avec des grosses perfs séquentielles (inutiles)

Bon alors.. Personne pour tenter le discard ?

Si, j'ai testé le discard online (dan /etc/fstab) sur un kernel 3.13.6 (m500 non blacklisté). Une compil kernel complète (2 x "make clean && make -j4" ) qui avait provoqué une corruption fs il y a un mois passe maintenant sans souci.
 
Pour autant je ne vais pas garder le discard online. Crucial ne communique pas sur les bugs corrigés, et je n'ai pas confiance. D'autant plus que le gain queued trim est maigre par rapport au non queued trim (quelques secondes sur la compil kernel) et nul par rapport à un trim batch...
 
Vous faites ce que vous voulez avec vos M500, mais je trouve que le trim batch n'est pas si lourd à gérer et bien plus sûr  

Sauf que là  si j'ai bien compris, c'est trim on (+ queue) ou pas de trim du tout non?
 
Il y a moyen de "choisir" quel trim on veut?

Tu as 3 options (pour le m500) :
1) discard online avec queued trim (firm MU05 + kernel qui ne blackliste pas le m500, de 3.12 à 3.12.6)
2) discard online SANS queued trim (peut importe le firm + kernel < 3.12 ou >=  3.13.7)
3)  trim batch (quelque soit le firm et la version kernel)
 
La solution 1) ne me parait pas trop sûre, vu le peu d'infos données par Crucial sur le firm MU05. Les 2) et 3) sont semblables à celles employées sur tous les ssd jusqu'à maintenant (avant sata 3.1)
 
EDIT: une chose est sûre: il faut éviter un firmware antérieur à MU05 ET une version kernel >= 3.12 et < 3.13.7  
 
RE-EDIT: par discard online, je veux dire trim activé via l'option de montage "discard" dans /etc/fstab...

Et la deux tu fais comment?

En sélectionnant un kernel qui ignore (ou blackliste)  la fonction queued Trim du  M500   (avec un kernel custom au besoin)

Oué c'est pas supra pratique quoi....

C'est sûr    Mais bon, personne n'a jamais prétendu qu'un bug devrait être pratique  

Bah il aurait pu y avoir un moyen facile d'activer ou pas le queue trim quoi. Choisir si on veut trim tout cours ou queue trim.
Genre discard ou un discard_queue

Tu vas voir, le démarrage sur un SSD avec les versions récentes de KDE ça déboite bien sévère.

vivi j'ai pas résisté , je suis sur la beta 2 de Kubuntu 14.04 que du bonheur

 
Et du coup tu as changé quelque chose à la configuration de base du système ?

A part noatime dans fstab.. Rien du tout.. Tout marche direct ! Et j'attends les avis de ce topic pour y ajouter le discard le jour ou il n'y aura plus aucun risque n'étant pas calé de ce côté

OK merci, et du coup tu as choisi quoi comme filesystem ?
(je vais bientot installer une 14.04 sur un NUC équipé d'un M500, donc je me renseigne )

bhaa EXT4

ext4 ne pose aucun problème sur les SSD d'après ce que j'ai pu constater, tout comme btrfs.