Reprise du message précédent :

Ok, merci
 
Pourquoi /var/log/ plutôt que /var ?

c'est le seul endroit où il y a potentiellement des écritures régulières sur mon système

Sur le PC d'une amie, qui vient d'acheter un SSD de 64 Go, j'ai réinstallé Kubuntu en mettant seulement / sur le SSD. Le /home et la swap sont sur le HDD. J'ai fait ça car vu qu'elle utilise Steam, et que Steam est stocké dans le home (répertoire .steam), je me suis dit qu'elle saturerait rapidement son SSD.
 
Mais en fait, maintenant que j'y pense, j'aurai pu mettre le /home sur le SSD, et déplacer Steam vu que Steam laisse la possibilité d'installer ses jeux ailleurs (sur le HDD donc). Du coup, un / et un /home sans Steam, ça doit tenir raisonnablement sur 64 Go, non ?

J'ai mon /home sur le SSD, et Steam sur le HDD, ça pose aucun soucis de places

Tout à fait. Personnellement, sachant que j'utilise Steam, avec un SSD de 512 Go (mais ce serait pareil si j'avais un petit SSD + un HDD de stockage) :
- / sur SSD, 15 Go
- /home sur SSD, 10 Go (fichiers courants pas lourds, etc)
- /media/Datas, le reste du SSD (ou le HDD de stockage)
Sous /media/Datas :
- un sous répertoire par type de données (Images, Vidéos, Musiques, Stock) avec des droits 750
- un sous répertoire Documents avec un sous répertoire par utilisateur avec les droits 700
- un sous répertoire Steam
Sous /home/kortex :
- un lien symbolique vers chacun des sous répertoires "type de données"
- suppression du dossier .steam, lien symbolique nommé .steam vers /media/Datas/Steam

Plus de problème de place, pas plus de problèmes de droits, facile à migrer.

Hop là

pour partager finement HDD et SDD il y a aussi moyen de s'en sortir avec des "mount --bind" ou des liens symboliques

Merci pour la réponse / confirmation, Kortex.

j'ai aussi des liens symboliques.
mon /home est sur le ssd et j'ai mis les liens photos, jeux, ... vers le hdd.
pour steam, j'ai simplement mis un lien pour un seul dossier, le sous-dossier où sont téléchargés les jeux.

Je pense que je vais mettre /var intégralement sur le HDD (après tout, y'a le cache de pacman, tout ça). Ça ralentirait pas grand-chose, si ?

ça dépend de ce que tu as sur /var
ça va surement ralentir un peu ton gestionnaire de paquets

Bon, j'ai redimensionné la partition racine hier soir, mais du coup, ça a "désaligné" la partition. Bizarre pourtant, car je l'ai simplement redimensionnée "à droite" avec Kparted, alors pourquoi ça me l'a désalignée à gauche ?

Enfin bon, j'ai pas constaté de baisse de perf. Au contraire même, ça va plus vite car le /home est désormais aussi sur le SSD...

Bonsoir,
 
Je compte m'acheter un SSD et j'aimerais un conseil, est-ce que ça vaut le coup d'y mettre LVM dessus ou seulement dans certain cas? (sachant que je ne vais pas faire de RAID).
 
Merci d'avance

La question est pas SSD/pas SSD: LVM c'est plus souple pour gérer ses disques, peu importe le support derrière.

Merci pour la réponse
Et sinon, l'option "discard" doit l'activer au niveau de LVM, du filesystem (ext4) ou des deux?

Aucun problème sur ArchLinux avec le Samsung 840 EVO 250GB, ça fonctionne même super bien.
 

Attention avec le discard sur les Crucial M500, il ne faut pas l'activer via /etc/fstab (surtout sur les kernels datant un peu) :
http://permalink.gmane.org/gmane.l [...] ead/432954
 
le 1° fix vers mi-décembre 2013 :

Salut
Merci pour l'info, un 3.10.17 sorti le 18/10/2013 c'est pas bon du coup ?

Ben si le premier fix est sorti mi Décembre...

 
 
vive le cache des samsung evo  

@gui42
 
Oui, ton noyau est trop vieux;  retires discard de /etc/fstab. Voir ce lien pour les dégats que ça peut provoquer :
https://bugs.launchpad.net/ubuntu/+ [...] ug/1259829
 
Ou alors faire un kernel custom :

Le noyau 3.14.0-rc7+ intègre le blacklistage des M500, et permet quand même de faire un fstrim (sans NCQ).

Ma question était stupide, pas taper.
fstab modifié, je vais rebooter dans une minute.
Par contre, si je comprends bien, même si j'upgrade le kernel, je peux pas remettre le discard ? et donc faut lancer fstrim à la mano ?
edit1 : (je veux dire, c'est pas un fix, c'est juste une blacklist, non ?)
edit 2 : c'est matériel, pas le pilote linux (?), donc y'a une petite chance que Crucial sorte un nouveau firmware...

Dans le lien que j'ai donné plus haut, un mainteneur kernel suggère que même le fstrim peut déraper (ça passe bien chez moi) :

A vrai dire, ce qui m'interpelle, c'est que je n'ai aucun problème sous W8.1 avec ce SSD crucial M500, alors que j'ai eu une corruption GPT et plusieurs corruptions ext4 (fs remonté en readonly) avec un kernel Fedora récent (3.13.6). Donc, MS fait peut-être la même chose que Linux maintenant: blacklist, et trim sans ncq (et ça n'est pas crié sur les toits). Et dans ce cas un nouveau firmware n'est pas à exclure?  
 
Bref, à suivre  

j'ai pas eu de problème jusque là mais  
à suivre ouais, j'espère qu'ils vont vite faire quelque chose parce que c'est ce qui évite d' "user" le ssd.
Merci encore

Bon , j'ai creusé un peu le sujet et apparemment j'ai dit des bêtises.  
 
Les soucis avec le M500 ne se produisent qu'avec le queued TRIM introduit avec le sata 3.1. Et le  sata 3.1 n'est supporté dans le kernel qu'à partir de la version 3.12 :
https://lkml.org/lkml/2013/9/3/277
Donc, ton kernel 3.10 ne doit pas souffrir de ce bug, puisqu'il ne peut pas faire de queued TRIM...
 
Par contre, d'après ce que j'ai compris avec un kernel antérieur à 3.12 il est préférable d'utiliser fstrim périodiquement plutôt que de mettre une option discard dans /etc/fstab :  
http://arstechnica.com/civis/viewt [...] &t=1219947
 

 
Ca n'empêche pas que j'aimerai bien que Crucial corrige le tir avec le queued TRIM...

Entre ça et les problèmes qu'il y a eu sur les M4 qui se crashait avant une correction dans je ne sais plus quelle version du firmware, je trouve que Crucial est pas au top dans le genre.
Leur SSD sont bons (je suis particulièrement satisfait du mien pour tout dire, mis à jour comme il se doit pour ne pas qu'il devienne une brique), mais ils sont un peu abonné aux firmware qui merdent. Je ne sais pas si c'est pareil ailleurs et avec autant de gravité (brick) mais ça m'interpelle.

en fiable, il ne va pas rester grand monde, à part intel (plus cher)...

Pour ce problème particulier (queued trim), on ne sait pas trop qui est fiable ou pas, vu que peu de SSD supportent  la norme ata 3.1; samsung 840 evo et crucial m500, oui c'est sûr d'après ce que j'ai pu googler.
 
Par exemple le 840 Pro ne la supporte pas (alors que c'est un ssd plutôt  récent) ?

punaise, si tu ne deviens pas expert, tu peux trop te planter en fait !

Que veux-tu dire ?  
 
Edit: je crois avoir compris pourquoi mon M500 déconne sous Linux, mais marche bien sous W8.1. MS a sans doute décidé de ne pas utiliser la feature "queued trim" , par peur d'une corruption massive sur les SSD supportant plus ou moins bien l'affaire (style m500). C'est déconnant ou pas ce que je raconte ?  

Que je n'ai plus de repères...
Si en plus, ce sont TOUS les SSD récents ui sont touchés, ça devient nawak !  
Bref, y'a intérêt à bien se documenter avec d'acheter ! (heureusement, c'est pas à l'ordre du jour pour moi)

merci beaucoup pour le suivi  

IL n'est question que de crucial là.
 
Pas tous donc.
 
Niveau dd fiable, oui intel jusque là c'est du tout bon. Mon 520 n'a jamais été mis à jour, c'est dire. Il n'existe aucune mise à jour. Il n'y a pas non plus de bug pour ainsi dire.  
 
Le 840pro de samsung semble aussi être un bon produit.  

OCZ-OCTANE (1.13) ici, rien à dire, ca roule bien.

Je ne sais pas; il n'est pas vraiment question de Crucial ou pas mais d'un certain mode de Trim (queued Trim) que l'Intel 520, le 840 Pro et l'Octane cités sont incapables d'effectuer (mais je peux me tromper)
 
A ma connaissance, seuls les 840 Evo et les M500 sont compatibles ATA 3.1. ET donc les seuls à pouvoir présenter un problème avec le queued Trim... J'ai effectivement rencontré un problème avec le M500, mais est-ce que le 840 Evo en est exempt ?
 
A noter que le crucial M500 est OK sous W8.1, et maintenant OK sous Linux  depuis qu'on ne peut plus effectuer de queued Trim dessus. J'aimerai bien des retours de possesseurs de 840 Evo qui ont activé le discard dans les options de montage ?

 
Salut,
 
Je n'ai pas l'impressions que ça déconne et je ne vois rien d'anormal dans les logs. Tu penses qu'il faudrait mieux que je passe quand même en fstrim via cron,  pour éviter tout problème futur ?
 
(3.13.6-1-ARCH)

Si tu n'as rien vu dans les syslog,  je pense que c'est OK; avec les kernel Fedora (à partir de 3.12+), j'a eu très vite des erreurs dans les logs (suite à des suppressions de fichiers), suivis de remontage des fs en read-only.
 
Donc il semblerait bien que Samsung fait mieux que Crucial sur ce coup là

  , pour le moment rien de tout ça chez moi, mais je suis en discard depuis seulement une semaine.
 

 
Et le TRIM est bel et bien effectif.
 

Check if TRIM works

Bonjour.
 
J'utilise un  :
 

 
Après lecture de pas mal d'informations sur le sujet, ici et ailleurs, j'utilise bien sûr les optimisations conseillées.
Dans le /etc/fstab :  
 

 
Un mount me donne :  
 

 
Quelle est cette option dans la sortie du mount : user_xattr que n'ai pas écrite dans le fstab ? Que fait-elle là ?  
 
Le tout sur une Gnu/Debian 7.4
 
Merci.

C'est une option de montage, donc...
man mount :

Je n'ai pas de man pour attr...
Ça doit se trouver sur le ouaib...

EDIT : http://linux.die.net/man/5/attr
Pas le courage de lire, à toi de jouer...

eXtended Attributes, c'est pour utiliser des blocs plus grands pour les métadonnées.

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 ?