Bonjour ;
Je me demande si vous avez tester les disques dure SSD sous Debian ? Si oui, qu’en pensez vous d’un point de vu technique ?
Mon EeePC 1005pe est super content, extrêmement plus rapide, silencieux, et bonus: a gagné en autonomie grâce à son SSD de 60G acheté d’occasion à 25€.
Mon G53SW vient de recevoir son deuxième disque SSD 128G, et il chauffe beaucoup moins.
Le premier disque SSD m’a été offert avec mon G53SW, et il tourne depuis un peu plus de deux ans (3 je crois) => trop peu pour voir côté fiabilité.
J’avais pensé faire un RAID0 ou RAID1 pour tester, mais ça fonctionne tellement bien comme ça que j’ai préféré laisser tout ça sans RAID.
J’ai connecté (USB) un très vieux SSD intel X25 de 40G sur mon EeePC 900 qui reste presque tout le temps allumé (serveur OpenVPN),
bientôt je l’amputerais de ces deux horribles cartes SSD MiniPCI d’origine (qui ne valent rien), et je testerai son autonomie sur batterie.
Je ne regrette pas du tout mon investissement qui m’a donné tout ce que j’en attendais: plus de vitesse, moins de bruit, plus d’autonomie, moins de chaleur dégagée, moins de bruit du ventilateur.
Hola !
Je tourne sur un Asus R700V sous Debian (7.6)
Je n’ai malheureusement pas suivi les conseils donnés ici :
p3ter.fr/article53/optimiser-son-ssd-sous-linux
forum.hardware.fr/hfr/OSAlternat … 9473_1.htm
Et pourtant ça fonctionne du tonnerre . Etant donné que je n’ai pas activé le trim je saurait pas tellement affirmer que ça change quelque chose ou pas , m’enfin même en installant bêtement l’OS ça rend très bien et je sens la différence avec le HDD à 5400 rpm !
Si tu es encore dans la phase je me pose des questions , fonce et optimise tout ça comme il faut 
Nickel chrome !
T’imagines pas le temps sur l’accès disque que ça te fait gagner.
Par contre, économise-le un peu en suivant ces conseils : libre-ouvert.toile-libre.org/?ar … t4-noatime
J’utilise 15 Go de partition système sur un SSD de 120 Go depuis 2 ans (tu mets /usr et /home sur un HDD). Bref, t’as vraiment besoin de peu en capacité SSD pour booster ta Debian…
[size=85]J’aimerais bien voir ta tête quand tu vas lancer ton premier apt-get avec SSD.[/size]
Pourquoi ne pas mettre /usr sur le SSD alors que ce répertoire contient la majorité des programmes et est essentiellement utilisé en lecture, ce qui en fait un candidat idéal ? C’est plutôt /var qu’il vaut mieux laisser ailleurs.
Pascal, est-ce que le fait de placer /var sur un DD Sata ne réduit pas sensiblement l’avantage de la rapidité que le SSD a apporté ?
Selon ta réponse, je ferai ptet l’essai, si la modification n’est pas trop compliquée pour mon neurone.
Actuellement, je n’ai que 3 partitions sur mon SSD : ‘/’ ; /home ; Swap.
Sur la machine, il y a un second DD Sata où la place ne manque pas.
Salut Aresh
C’est le jour est la nuit pour la vitesse en générale, notamment le boot et pourtant je ne l’ai pas non plus optimisé (et j’ai pas forcement opté pour du haut de gamme en terme de performance).
Comme Pascal /var et mes données sont restés sur un HDD:
SDD:
/boot (ext3)
/ (btrfs)
/home (btrfs)
HDD:
/var (btrfs)
/data (ext4)
J’avoue que pour le moment, n’étant pas trés rigoureux dans mes sauvegardes de données, je ne me risque pas à mettre mes données sur du ssd (et de toute façon ça aurait un cout un peu trop élevé à mes yeux).
/usr est beaucoup trop gros par rapport aux autres dossiers, du fait qu’il contienne la majorité des programmes. J’essayais de lui proposer la solution la moins consommatrice d’espace SSD.
Le mettre sur HDD me permet aussi d’en faire un backup plus souvent. 
Maintenant, pourquoi ne pas mettre /var sur HDD ?
Car /var est un dossier système, qui contribue largement à la rapidité système (apt-get ne serait pas aussi rapide si je laissais /var sur HDD par exemple 
).
Est-ce-que quelqu’un a testé le chiffrement des partitions sur SSD ?
Ca m’intéresse de plus en plus, mais j’ai peur de la perte de performances.
[quote=“TheJeje20”] Maintenant, pourquoi ne pas mettre /var sur HDD ?
Car /var est un dossier système, qui contribue largement à la rapidité système (apt-get ne serait pas aussi rapide si je laissais /var sur HDD par exemple ).[/quote]
/var est une arborescence très sollicitée en écriture (fichiers journaux), et ce sont les écritures qui usent les SSD.
/usr par contre est peu utilisé en écriture (uniquement ou presque lors d’installations/désinstallations), mais beaucoup en lecture. Le candidat idéal pour passer sur un SSD !
Je m’interroge sur un cas particulier : les liens symboliques sur un DD pointant sur des fichiers sur un SSD. Quid des performances ?
Le temps d’accès dans ce cas étant limité par les capacités du DD (du moins je suppose), est-ce que je ne perdrais pas beaucoup de l’intérêt du SSD ?
Voici un exemple que j’ai en tête, que j’utilise essentiellement pour des jeux Windows via WINE, où les fichiers nécessitant des droits en écriture sont copiés localement (sous $HOME) alors que ceux n’ayant besoin d’être accessible qu’en lecture sont des liens symboliques vers les fichiers originaux sous /usr :
~/.local/share/games/starcraft$ ls -l
total 96
lrwxrwxrwx 1 dave dave 43 avril 17 16:11 battle.snp -> /usr/local/share/games/starcraft/battle.snp
-rw-r----- 1 dave dave 84819 avril 22 06:37 bncache.dat
-rw-r----- 1 dave dave 814 avril 22 06:37 BnetLog.txt
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 bnupdate.exe -> /usr/local/share/games/starcraft/bnupdate.exe
lrwxrwxrwx 1 dave dave 44 avril 17 16:11 broodat.mpq -> /usr/local/share/games/starcraft/broodat.mpq
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 broodwar.mpq -> /usr/local/share/games/starcraft/broodwar.mpq
drwxr-x--- 2 dave dave 4096 août 9 16:27 characters
lrwxrwxrwx 1 dave dave 46 avril 17 16:11 editlocal.dll -> /usr/local/share/games/starcraft/editlocal.dll
lrwxrwxrwx 1 dave dave 43 avril 17 16:11 instcc.exe -> /usr/local/share/games/starcraft/instcc.exe
lrwxrwxrwx 1 dave dave 42 avril 17 16:11 local.dll -> /usr/local/share/games/starcraft/local.dll
drwxr-x--- 8 dave dave 4096 avril 3 03:05 maps
lrwxrwxrwx 1 dave dave 43 avril 17 16:11 noboot.dat -> /usr/local/share/games/starcraft/noboot.dat
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 patch_rt.mpq -> /usr/local/share/games/starcraft/patch_rt.mpq
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 riched20.dll -> /usr/local/share/games/starcraft/riched20.dll
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 seditdeu.loc -> /usr/local/share/games/starcraft/seditdeu.loc
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 seditenu.loc -> /usr/local/share/games/starcraft/seditenu.loc
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 seditesp.loc -> /usr/local/share/games/starcraft/seditesp.loc
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 seditfra.loc -> /usr/local/share/games/starcraft/seditfra.loc
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 seditita.loc -> /usr/local/share/games/starcraft/seditita.loc
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 seditptb.loc -> /usr/local/share/games/starcraft/seditptb.loc
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 seditptg.loc -> /usr/local/share/games/starcraft/seditptg.loc
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 smackw32.dll -> /usr/local/share/games/starcraft/smackw32.dll
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 standard.snp -> /usr/local/share/games/starcraft/standard.snp
lrwxrwxrwx 1 dave dave 46 avril 17 16:11 starcraft.exe -> /usr/local/share/games/starcraft/starcraft.exe
lrwxrwxrwx 1 dave dave 46 avril 17 16:11 starcraft.mpq -> /usr/local/share/games/starcraft/starcraft.mpq
lrwxrwxrwx 1 dave dave 44 avril 17 16:11 stardat.mpq -> /usr/local/share/games/starcraft/stardat.mpq
lrwxrwxrwx 1 dave dave 45 avril 17 16:11 staredit.exe -> /usr/local/share/games/starcraft/staredit.exe
lrwxrwxrwx 1 dave dave 42 avril 17 16:11 storm.dll -> /usr/local/share/games/starcraft/storm.dll
(question théorique, je n’utilise pas encore de SSD)
Oui, je ne dis pas le contraire!
Mettre /var sur SSD use le SSD à cause des écritures. Mais c’est un prix à payer pour un gain de performances non négligeable.
Sinon, ya toujours la méthode du RAMDisk (j’ai monté mon dossier /tmp en RAMDisk). Mais s’il y a coupure de courant, tu perds les changements.
On peut mettre /var/log en RAMDisk, ce qui réduit considérablement les accès en écriture. (Editer /etc/rc0.d/K00nomduscript pour synchroniser avec le DD à l’extinction)
Pour ceux que ça intéresse :
http://www.generation-linux.fr/index.php?post/2009/05/04/tmpfs-%3A-utiliser-sa-ram-comme-repertoire-de-stockage
Je précise que je n’ai pas encore utilisé Linux avec un SSD, mon opinion n’est donc pas basée sur une expérience personnelle mais uniquement sur mes réflexions.
Réponse de Normand : cela dépend de l’utilisation de /var. Sur un poste de travail où il sert surtout à stocker des logs (donc surtout en écriture), je ne pense pas. Par contre si /var contient des bases de données en utilisation intensive, c’est probable que oui.
C’est vrai mais il faut relativiser par rapport à la capacité d’un SSD. Sur un système classique /usr ne devrait pas dépasser 10 Go. N’importe quel SSD pas trop vieux a suffisamment de capacité.
[quote=“TheJeje20”]Maintenant, pourquoi ne pas mettre /var sur HDD ?
Car /var est un dossier système, qui contribue largement à la rapidité système (apt-get ne serait pas aussi rapide si je laissais /var sur HDD par exemple[/quote]
As-tu comparé en pratique la rapidité d’apt-get dans les deux cas ?
Je ne pense pas qu’apt-get serait significativement ralenti avec /var sur un disque dur, selon le raisonnement suivant : lors de l’installation ou de la mise à jours de paquets, l’écriture des fichiers dans /var se fait à la vitesse du réseau donc ce n’est pas le disque qui limite (sauf réseau monstrueux et disque minable). Ensuite lors du dépaquetage des fichiers .deb téléchargés, ceux-ci ont de grandes chances de se trouver encore dans le cache disque (pagecache) en RAM, donc peu importe la vitesse du disque qui ne sera pas sollicité. Le seul moment où apt-get gagnerait en rapidité sur un SSD, c’est lors de la lecture de la liste et de l’état des paquets.
En tmpfs, tu veux dire ? Ramdisk et tmpfs sont deux choses très différentes.
-
ramdisk = périphérique bloc en RAM, dans lequel on peut mettre n’importe quoi, par exemple un système de fichiers ext4, dont la taille est fixée à la création. Plus très utilisé de nos jours.
-
tmpfs = système de fichiers en mémoire virtuelle (RAM + swap), dont la taille est limitée mais variable.
Je teste Debian Jessie, utilisation desktop Gnome, sur un SSD (destockage 40Go Intel, ancienne gamme, “lent” comparé aux derniers modèles)
L’installeur Debian sait gérer les SSD depuis belle lurette (alignement des partitions), mais on doit rajouter manuellement les options “discard” et “noatime” des partitions. Le trim est géré automatiquement par les modèles de SSD récent.
Le rootfs prend 4.5G.
On peut désactiver le swap si on a assez de RAM (ou mieux mettre vm.swappiness=0 dans sysctl.conf)
Bref, pas de crainte à avoir 
[quote=“agentsteel”] sur un SSD (destockage 40Go Intel, ancienne gamme, “lent” comparé aux derniers modèles)
L’installeur Debian sait gérer les SSD depuis belle lurette (alignement des partitions), mais on doit rajouter manuellement les options “discard” et “noatime” des partitions. Le trim est géré automatiquement par les modèles de SSD récent.
[/quote]
tu peux montrer ton fstab que je le compare au mien issu d’une install automatique sur le même SSD ? merci
[code]# /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).
UUID=e02c8bd3-4a54-4414-b66c-0c53daec527f / ext4 defaults,rw,relatime,data=ordered 0 1
UUID=d844393b-572f-4ea0-816c-6f0b7884cde4 /boot ext2 defaults,rw,relatime 0 0
UUID=09ba2ad0-9fae-4634-9fe5-3a6a6ee413fb swap swap defaults 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0[/code]
# / was on /dev/sdb2 during installation
UUID=xxxxxx-a9a8-xxxx-9175-60c10c0bb125 / ext4 discard,noatime,errors=remount-ro 0 1
# /boot/efi was on /dev/sdb1 during installation
UUID=xxxx-xxxx /boot/efi vfat defaults 0 1
# /home was on /dev/sdb4 during installation
UUID=xxxxxxx-4a97-xxxx-a228-8b6281a6e89c /home ext4 discard,noatime 0 2
# swap was on /dev/sdb3 during installation
UUID=xxxxxxx-0a08-44a2-xxxx-0ce3ddc9db88 none swap sw 0 0J’ai bien modifié /etc/default/tmpfs avec
[mono]RAMTMP=yes[/mono]
mais ça n’a pas l’air d’être effectif, du coup je vais rajouter la ligne pour /tmp comme dans ton fstab
d’après le [mono]man mount[/mono], [mono]data=ordered[/mono] est la valeur par défaut, donc pas besoin de le spécifier
Merci à tous, je suis entrain d’étudier la question du changement de mon disque dur sur mon PC. La question du SSD est donc important. Je pense que je vais opté pour cette solution, sachant que j’ai un PC qui me sert surtout de PC de bureautique (écriture de texte, un peu de 3D sous Blender, retouche photo).
Le seul soucis, le prix du disque, 79 €, je vais donc économiser un peu avant de me payer ce disque. 
Le samsung 840 pro a changé la vie de mon D630.
Le disque dur classique est vraiment LE bottleneck d’un PC…