Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide Recherche
483 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  Hardware

  [Topic Unik] Les SSD sous Linux : recensement, optimisation, conseils

 

 

 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  39  40  41  42  43  44
Page Précédente
Auteur Sujet :

[Topic Unik] Les SSD sous Linux : recensement, optimisation, conseils

n°1134724
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 12-05-2009 à 14:52:44  profilanswer
 

Bienvenue sur le topic des SSD sous Linux :)

 

Ce topic se veut le plus complet possible en ce qui concerne l'utilisation des SSD sous Linux. En effet, si on trouve de nombreuses informations concernant l'utilisation et la configuration des SSD sous Windows, les même informations appliquées à Linux sont plus rares et plus difficiles à dénicher. Ainsi, ce topic se chargera de compiler toutes les informations glanées sur le net ou issues de l'expérience des utilisateurs d'HFR de SSD sous Linux.

 

Sommaire
I. Généralités sur les SSD
II. Installer sa distribution sur un SSD
III. Conseils et astuces pour optimiser son SSD
IV. Recensement des utilisateurs de SSD sous Linux

 

I. Généralités sur les SSD

 
  • Présentation de la technologie SSD

Les SSD (pour Solid State Drive) représentent les unités de stockages destinées à remplacer nos traditionnels disques durs (HDD pour Hard Disk Drive). Ils sont basés sur la mémoire Flash en lieu et place des plateaux magnétiques. C'est dans les cellules des puces de mémoire Flash que l'on lit et écrit les données. Afin de réaliser ces opérations, un contrôleur dédié intégré au SSD reçoit les requêtes et les traite, épaulé ou non suivant les modèles par de la mémoire cache.

 

Les avantages de cette technologie sont :
     - l'inexistence d'usure mécanique puisqu'aucune pièce n'est en mouvement, ce qui induit l'insensibilité (relative certes) aux chocs et un total silence de fonctionnement;
     - des débits au dessus des meilleurs HDD, surtout pour les dernières génération de SSD qui accrochent les 220 Mo/s en lecture séquentielle, et flirtent avec les 200 Mo/s en écriture séquentielle (on est proche du Go/s pour les SSD professionnels sur carte PCI-Express, à des prix complètement indécents , voir ici). Ces débits sont nettement inférieurs en lecture ou écriture aléatoire, mais toujours nettement au dessus des débits dans les même conditions des HDD;
     - des temps d'accès nettement inférieur à ceux des HDD, puisqu'on parle généralement de temps compris entre 0.2 et 0.1 ms, voir moins, là où les HDD se situe entre 5 ms (15000 trs/min SAS) et 15 ms (7200 trs/min SATA);
     - une consommation électrique inférieure environ de moitié par rapport aux HDD, même si les HDD 2"1/2 sont proches des consommation des SSD, avec à la clé un dégagement thermique inférieur;
     - l'insensibilité à la fragmentation des système de fichiers puisque, contrairement aux HDD, il n'est pas nécessaire d'attendre une mécanique lente pour accéder à deux informations situés à des emplacements physiquement éloignés sur le SSD (comprendre dans des puces mémoires différentes par exemple);

 

Néanmoins, les SSD n'ont pas que des avantages, et on peut leur reprocher :
     - une durée de vie limitée par le nombre de cycles lecture/écriture auxquels sont soumises les puces mémoire, même si des mécanismes de minimisation de l'usure sont mis en place au niveau des contrôleurs sur les SSD (wear levelling);
     - des capacités des stockage plus faibles que celles des HDD, même si cela tend petit à petit à s'améliorer;
     - un prix au Go largement plus élevé que celui des HDD, ce qui signifie qu'à capacité égale, un SSD coutera beaucoup plus cher qu'un HDD;

 
  • Caractéristiques essentielles d'un SSD

Comme toute technologie, les SSD connaissent un phénomène de gamme qui les place sur une échelle, aussi bien en terme de prix qu'en terme de performances, les deux étant souvent liés. Ainsi, pour choisir son SSD, on pourra se fier au caractéristiques suivantes :
     - le type de cellules mémoire utilisées : on distingue deux types de cellules Flash dans les SSD : les SLC (Single Level Cell) et les MLC (Multi Level Cell). En résumé, les puces SLC sont plus rapides, ont une meilleure durée de vie mais sont également beaucoup plus chères et ont des capacité de stockage inférieur aux MLC. Ainsi, les SLC seront réservées aux SSD très haut de gamme et souvent de faible capacité, là où les SSD abordables et de capacité importante seront systématiquement basés sur des puces MLC;
     - le contrôleur : c'est une pièce maitresse d'un SSD, dans le sens ou un contrôleur de mauvaise qualité ne permettra pas de restituer les performances que les puces Flash peuvent offrir. C'est ce qui s'est passé sur les premières générations de SSD basé sur des contrôleurs JMicron JM601 ou JM602, qui sont à éviter absolument. Les contrôleur Indilinx, Intel ou Samsung offrent quand à eux des performances stables et satisfaisantes;
     - le support du TRIM : le TRIM est une technologie permettant d'améliorer les performances dans le temps des SSD. En effet, en raison de leur principe de fonctionnement, les SSD ont tendances à voir leurs performances baisser au fur et à mesure qu'on les utilise. Le TRIM tend à réduire, voir à supprimer, cette baisse de performance. Pour plus de précision, le principe de fonctionnement des SSD et du TRIM est expliqué dans cet article. Le TRIM doit être supporté par le SSD mais également par l'OS. Les SSD à base de chipset Indilinx ou SandForce ainsi que les SSD Intel supportent le TRIM. Le noyau 2.6.33 permet d'appliquer le TRIM à la volée avec ext4, moyennant un montage des partitions accompagné de l'option discard. Pour les autres cas (ext3, kernel antérieur au 2.6.33), il faudra passer par un script manuel qui permet de trimmer ses partitions une à une. Ce script est disponible ici;

 
  • Vocabulaire de la technologie SSD

    - alignement des partitions : même si l'alignement des partitions n'est pas spécifiques aux SSD, il n'a que très peu d'importance sur un spinoff, sauf dans le cas des volumes RAID5. L'alignement consiste à faire correspondre les blocs logiques des partitions avec les blocs physiques du SSD pour améliorer les performances de celui-ci afin de limiter les opérations de lecture et d'écriture. L'alignement des partitions fait l'objet d'un paragraphe à part dans la section suivante.
     - wear-levelling : c'est une technique utilisé par les contrôleurs des SSD. Elle consiste à répartir l'usure des puces mémoires en écrivant le moins souvent possible dans les même cellules, et en profitant ainsi au maximum du nombre de cycles de lecture/écriture de chacune des cellules. De ce fait, avec un bon algorithme de wear-levelling, on arrive à faire en sorte qu'un SSD ait une durée de vie de l'ordre de plusieurs années.
     - garbage collector : dixit HFR himself, c'est un mécanisme visant à réorganiser la table d’allocation à la volée, ce qui permet de conserver un bon niveau lors d’écritures séquentielles sur une zone précédemment écrite de manière aléatoire. Avantage : on récupère les performances d'origine du SSD en écriture séquentielle ou presque. Inconvénient : on génère de nombreuses écritures dans les puces mémoire, ce qui a tendance à amoindrir la durée de vie du SSD, et le disque travaillant en interne, il ne libère pas les pages de Flash comme le fait le TRIM, ce qui fait que cela n'a n'est efficace que pour les écritures séquentielles, sans améliorer les écritures aléatoires. Plus de précisions dans cet article. Tous les SSD semblent utiliser ce procéder, de manière plus ou moins agressive, et ce à la volée ou en tâche (on parle alors de background garbage collection) de fond en fonction de l'objectif du fabricant.

 

Pour en savoir plus, je vous propose la lecture de cet article, plutôt bien fait (en anglais malheureusement) :
http://arstechnica.com/information [...] ally-work/

Message cité 1 fois
Message édité par Kortex@HFR le 11-06-2012 à 08:45:20

---------------
Paisible, sous l'Arch - Mon feed
mood
Publicité
Posté le 12-05-2009 à 14:52:44  profilanswer
 

n°1134725
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 12-05-2009 à 14:52:59  profilanswer
 

II. Installer sa distribution sur un SSD

 

/!\ Attention, cette méthode ne vaut que pour les versions antérieures à la 2.2 de parted. Au delà, parted réalise automatiquement un alignement sur 2048 secteur, ce qui est parfait pour tous les SSD, sans avoir à calculer quoi que ce soit. Il est ainsi à nouveau possible de partitionner simplement, en utilisant le Mo ou le Go comme unité. La création des système de fichier reste en revanche d'actualité.

 
  • Partitionner son SSD - Méthode avec table de partitions classique

Cette méthode semble donner de bons résultats. Elle repose principalement sur les recherches de [albator] que je remercie chaleureusement pour nous avoir fait profiter de ses résultats. J'ai moi-même repris cette méthode pour partitionner et formater mes partitions, avec succès.

 

J'ai démarré l'installeur de Arch depuis ma clé USB. Pour une autre distribution, il faudra démarrer une session Live ou utiliser un CD spécifique comme Ultimate Boot CD ou quelque chose d'équivalent. Une fois connecté, en console, je me suis servi de parted. Je me retrouve donc sur l'invite de parted, première vérification : la version du SSD :

(parted) print
Model : ATA OCZ-Vertex v1.10
Disk /dev/sda : 128 GB
Sector Size (logical/physical) : 512B/512B


La version du SSD en 1.10, c'est parfait, c'est la dernière version disponible, pas besoin de flasher le firmware.
La taille d'un bloc, étant de 128 Ko, et un secteur représentant 512 o, on en déduit que chaque bloc est composé de 256 secteurs (128 Ko / 512 o). On va donc aligner les partitions en comptant le nombre de secteur, de manière à ce que chaque début de partition tombe sur un multiple de 256, soit un début de bloc. D'autre part, afin de tenir compte du premier secteur réservé on va volontairement décaler la première partition jusqu'au premier secteur multiple de 256. Cela ne gâche que quelques Ko et permet de rester aligné quoi qu'il arrive.
Commençons par déterminer quel est le dernier secteur du SSD, en changeant d'abord l'unité utilisée pour afficher les informations du SSD (l'unité devient le secteur) :

(parted) unit s
(parted) print free
Number    Start     End           Size          Type   File        System Flags
          0s        50069679s     250069680s           Free Space


A l'aide d'un petit tableau sous Calc (que vous pouvez télécharger ici), j'ai calculé, à partir de la taille souhaitée de mes partitions, le secteur de début et de fin de chacune de mes partitions en suivant la règle suivante :
Taille de la partition en secteurs = taille de la partition en Mo * 1024 * 1024 / 512
Une partition est donc définie par son secteur de début et son secteur de fin, ce dernier étant le secteur de début + la taille de la partition en secteur - 1 (on retranche 1 pour tenir compte du secteur du début). La partition suivante commence au secteur suivant qui sera forcément, grâce à la méthode de calcul, un multiple de 256.
Du coup, j'en ai déduis le tableau suivant :


Partition       Point de montage        Debut           Taille (Mo)     Fin
/dev/sda1       /                       256             8400            17203455
/dev/sda2       swap                    17203456        256             17727743
/dev/sda3       /home                   17727744        5000            27967743
/dev/sda4       /media/Datas            27967744        le reste        250069679


Du coup, dans parted, il devient très simple de créer ses partitions à partir des infos calculées :

(parted) mkpart primary 256 17203455
(parted) mkpart primary 17203456 17727743
(parted) mkpart primary 17727744 27967743
(parted) mkpart primary 27967744 250069679


On peut vérifier le résultat une fois les partitions créées :

(parted) print
Number  Start           End             Size            Type     File System    Flags
1       256             17203455        17203200        primary
2       17203456        17727743        524288          primary
3       17727744        27967743        10240000        primary
4       27967744        250069679       222101936       primary


Si on affiche à nouveau les informations avec l'octet comme unité, on peut vérifier la taille des partitions de manière plus parlante :

(parted) print
Number  Start           End             Size            Type     File System    Flags
1       131kB           8808MB          8808MB          primary
2       8808MB          9077MB          268MB           primary
3       9077MB          14.3GB          5243MB          primary
4       14.3GB          128GB           114GB           primary


Il ne reste plus qu'à placer le drapeau de boot sur la première partition pour s'assurer du bon fonctionnement du bootloader et du chargement du futur OS:

(parted) set
1
boot
on


Le résultat en vérification :


Number  Start           End             Size            Type    File System     Flags
1       131kB           8808MB          8808MB          primary                 boot


Il faut maintenant créer les système de fichiers. De mon côté, je passe par ext4, que je monterai ensuite avec l'option noatime pour ne pas provoquer d'écriture lors d'une simple lecture. Là encore, on se sert des options de formatage du système de fichiers ext4 pour aligner la partition. Il faut aligner la partition avec des blocs logique de 4 Ko (4096 o), et un stride respectant l'alignement des blocs physique du SSD. Les blocs logiques font 4 Ko, on sait que les blocs physique font 128 Ko, on aura donc un stride de 32 (128 Ko / 4 Ko). J'avoue ne pas trop comprendre cette histoire de stride, mais l'utilisation de ces deux valeurs permet visiblement de tout aligner correctement. On créé donc les systèmes de fichiers ext4 sur les partitions adéquat :

# mkfs.ext4 -b 4096 -E stride=32 /dev/sda1
# mkfs.ext4 -b 4096 -E stride=32 /dev/sda3
# mkfs.ext4 -b 4096 -E stride=32 /dev/sda4


Si vous souhaitez utiliser ReiserFS, il est possible de formater vos partitions en foçant  la taille des blocs logique, mais pas le stride. Ne sachant pas quelle est l'influence de ce paramètre, je ne sais pas si cela va réellement dégrader les performances ou pas, mais a priori, cela reste négligeable voir même inexistant :

# mkreiserfs -b 4096 /dev/sda1


Si quelqu'un sait comment forcer ces paramètres sur la partition de swap, je suis preneur. Même si au final je ne monte pas cette partition, ArchLinux impose d'avoir une partition de swap au moment de l'installation, donc autant que cette dernière soit également alignée.
Ensuite, lors de l'installation, on définit les point de montage, mais on ne les formate pas. Il le sont déjà, et un nouveau formatage ne réutiliserait pas forcément les valeurs de bloc et de stride que l'on a utilisé, ruinant alors l'alignement.
Pour terminer, une fois la distrib installée, j'ai placé, comme indiqué dans les astuces plus bas, le /tmp en tmpfs, désactivé le montage de la partition swap dans fstab, désactivé le démon de log et monté les partitions ext4 avec l'option noatime.

 
  • Partitionner son SSD - Méthode avec table de partitions GPT

Là encore, un grand merci à [Albator], décidemment, sans lui, ce topic n'aurait pas la même physionomie ;)

 

Avec cette méthode, on ne change que la façon de compter les partitions, mais pas celle de compter les blocs. Ainsi, on gardera les même partitions que dans la méthode précédente, avec les même secteurs de début et de fin, mais on utilise une autre façon de créer les partitions. Je vous conseille donc de lire la méthode précédente avant de vous lancer dans celle-ci qui en reprend les grands principes.
Le problème de la méthode précédente est qu'elle se limite à 4 partitions, puis que les tables de partitions stanbards se limitent à 4 partitions primaires. Une autre solution consisterait à ne créer qu'une partition étendue sur l'intégralité du disque dur, et de tailler ses lecteurs logiques dedans. Néanmoins, il existe une autre façon de créer ses partition : utiliser une table de partition de type GPT. Avec ce type de table, qu'on pourrait qualifier de "moderne", la nuance entre partition principale et étendue n'existe plus, toute les partitions étant du même type, et il n'y a plus de limite au nombre de partitions que l'on peut créer sur un disque.
Ce qu'il faut savoir avant de se jeter sur cette méthode, qui semble mettre tout le monde d'accord de prime abord :
- les partitions référencées dans une table GPT sont accessibles sous Windows comme sous Linux, mais a priori, seul Linux saura booter dessus via GRUB. Du coup, pas de multiboot Windows Linux avec cette méthode.
- les partitions référencées dans une table GPT portent forcément un label, ainsi il est préférable de savoir ce qu'on va mettre sur ses partitions avant de se lancer dans le partitionnement afin de donner aux partitions des labels cohérents.
- la création d'une table GPT efface l'intégralité du disque, donc on utise cette méthode lorsqu'on a un disque neuf ou après un gros backup de toutes ses données.

 

Ceci mis au clair, on peut partitionner le disque, toujours avec Parted. Pour cela, une fois parted lancé, on commence par créer la table GTP (c'est à ce moment que toutes les partitions antérieures et les données qu'elles contenaient deviendront innaccessibles) :

(parted) mklabel
Nouveau type d'étiquette de disque ? gpt


On change l'unité de parted pour le secteur :

(parted) unit s
(parted) print free
Number    Start     End           Size          Type   File        System Flags
          0s        50069679s     250069680s           Free Space


Ensuite, on créé les partitions en utilisant les secteurs trouvés par les calculs de la méthode précédente, en donnant à chaque partition le label qui correspond au type de données qu'elles vont recevoir :

(parted) mkpart linux_root 256 17203455
(parted) mkpart linux_swap 17203456 17727743
(parted) mkpart linux_home 17727744 27967743
(parted) mkpart linux_datas 27967744 250069679


Les partitions créées, on reprendra la méthode précédente pour la création des systèmes de fichiers, les règles sur la taille de bloc et de stride pour les volumes ext4 semblant toujours d'actualité avec ce type de partitionnement.

 
  • Choix du système de fichiers

Le choix du système de fichiers pour un SSD est problématique. En effet, comme on l'a dit précédemment, on cherche à éviter au maximum les écritures inutiles sur un SSD pour en préserver au maximum la durée de vie. Dans le même temps, les systèmes de fichiers modernes sont tous journalisés, c'est à dire qu'ils stockent de nombreuses informations sur les accès aux fichiers, ce qui génère de nombreuses écritures mais garantie également dans une certaine mesure la sécurité des données en cas de crash du système. On se trouve donc devant un conflit d'intérêt.

 

    - utilisation des système de fichiers optimisés pour les stockage sur Flash : on compte parmi ces système de fichiers JFFS2, LogFS ou UBIFS. Ils incorporent des optimisations permettant de limiter les entrées/sorties, et pour certains de journaliser. En revanche, il s'avère que dans le cas des SSD, ils ne sont pas spécialement adaptés car les SSD intègre désormais au niveau du contrôleur des algorithme effectuant déjà les optimisation susceptibles d'être utiles dans ces systèmes de fichiers. Le travail serait donc réalisé deux fois, ce qui est inutile. Pire, cela induirait dans certains cas des latences qui peuvent ralentir le système. En attendant BTRFS, ces systèmes de fichiers sont donc à exclure pour l'utilisation d'un SSD.

 

    - utilisation d'un système de fichier non journalisé :la première solution consiste à utiliser un système de fichiers non journalisé, c'est à dire concrètement ext2. Ce système de fichiers ne génère pas d'écriture particulière en dehors des sauvegardes de données explicites. Il aura donc tendance à économiser un SSD. Néanmoins, le risque de perte de donnnées en cas de crash est réel, et il faut donc l'utiliser en connaissance de cause.

 

    - utilisation des systèmes de fichiers journalisés : comme dis plus tôt, le principal intérêt des systèmes de fichiers journalisés est de garantir une (relative) sécurité des données en cas de crash du système ou d'extinction brutale de la machine. La journalisation entrant en conflit avec la durée de vie des SSD, il est difficile de faire un choix. Néanmoins, ce qui ressort des discussions sur le net et des déclarations des constructeurs autant que des sites spécialisés est que le wear-levelling permet de s'affranchir de ce problème, en gérant directement au niveau du contrôleur l'usure des puces mémoire. L'utilisation des systèmes de fichiers ext3, ext4 ou ReiserFS est envisageable sur les SSD assez récent, qui incorporent une bonne gestion du wear-levelling. On pourra néanmoins améliorer la gestion de la journalisation en se servant des options de montage des partitions journalisées, comme on le verra dans la partie III. A noter néanmoins que ext4 est l'étape précédent BTRFS, système de fichiers qui devrait inclure des optimisation spéciales pour les SSD. On peut donc imaginer que ext4 incorpore déjà une partie de ces optimisations, et qu'il est préférable à ext3 dans le cadre de l'utilisation d'un système de fichiers journalisé sur un SSD. Pour finir, on soulignera que seul ext4 supporte le TRIM à la volée pour les SSD qui le permettent (voir le paragraphe sur le TRIM dans le premier post).


Message édité par Kortex@HFR le 19-05-2011 à 10:53:44

---------------
Paisible, sous l'Arch - Mon feed
n°1134726
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 12-05-2009 à 14:53:05  profilanswer
 

III. Conseils et astuces pour optimiser son SSD

 

Au fil des discussions sur ce topic, voici une petite compilation des conseils et astuces permettant de tirer parti au mieux de son SSD ou d'en prendre le plus grand soin, notamment en ce qui concerne sa durée de vie.

 
  • Supprimer le swap

Cette astuce ne s'adresse qu'à ceux dont la machine dispose d'au moins 1 Go de RAM. Il est possible dans ce cas, et suivant l'utilisation que l'on fait de la machine de ne pas se servir de swap. Pour cela, soit on ne créé aucune partition de swap lors de l'installation de la distribution, soit, dans le fichier /etc/fstab, on commente la ligne montant le fichier swap :

UUID=bd746caf-bd0c-4649-baa7-d680bb91a6d0 swap swap defaults 0 0


devient alors :

#UUID=bd746caf-bd0c-4649-baa7-d680bb91a6d0 swap swap defaults 0 0


Il peut être préférable d'utiliser la méthode consistant à ne pas monter une partition de swpa existante, de manière à pouvoir la réactiver facilement en cas de besoin, l'utilisation du swap pouvant varier en fonction de l'utilisation de la machine.

 
  • Désactiver le logging

La plupart des démons logguent leurs activités. Or il est finalement assez rare d'aller consulter ces fichiers de log, car tant que la machine fonctionne correctement, il n'y a pas de raison de les lire pour le plaisir. Du coup, on peut tout simplement désactiver le démon permettant le logging. Ce démon, syslog, est démarré par le système au boot de la machine. Ainsi, en focntion de votre distribution, il faudra désactiver le lancement de ce démon.
Sous Arch, on pourra préfixer le démon syslog-ng d'un point d'exclamation pour en empêcher le démarrage.

DAEMONS=(!syslog-ng hal cpufreq !network wicd netfs crond mpd @kdm)


Comme pour le swap, il est préférable de désactiver le lancement du démon plutôt que de le supprimer purement et simplement, son utilisation pouvant être nécessaire en cas de problème.

 
  • Modifier les paramètres de journalisation

Par défaut, une partition en ext3 ou ext4 journalise non seulement les opérations d'écriture (ctime, l'heure de création, et mtime, l'heure de la dernière modification) mais également les opérations de lecture (atime l'heure du dernier accès), ce qui génère une écriture à chaque lecture. Dans le cas d'un SSD, c'est particulièrement problématique si on souhaite économiser la durée de vie de ce dernier. C'est pourquoi, on peut désactiver la journalisation de lecture lors du montage des partitions, dans le fichier /etc/fstab en ajoutant le paramètre noatime pour chacune des partitions ext3 ou ext4 hébergée sur le SSD :

UUID=db12430a-c622-4469-be4b-db24acb18922 / ext4 defaults,noatime 0 1


Pour ceux qui souhaitent utiliser ReiserFS de la même manière, c'est possible, avec la commande suivante :

UUID=db12430a-c622-4469-be4b-db24acb18922 / reiserfs defaults,noatime 0 1

 
  • Activer le TRIM à la volée

Si on dispose d'un SSD supportant le TRIM, qu'on utilise une distribution proposant au moins le kernel 2.6.33 et que l'on utilise ext4 comme système de fichier, on peut alors profiter des fonctions TRIM en temps réel et sans avoir à exécuter un script. Pour cela, il suffit d'ajouter l'option discard dans la ligne de montage des partitions concernées :

UUID=db12430a-c622-4469-be4b-db24acb18922 / ext4 defaults,noatime,discard 0 1


Attention : l'activation du TRIM peut provoquer des pertes de performances dans certains cas, retirez discard si vous constatez des baisses de performances et tournez vous vers un TRIM manuel régulier à l'aide du script Wiper.

 
  • Placer la dossier temporaire en RamDisk

Afin de limiter les accès au SSD et ainsi éviter les lectures/écritures inutiles, il est intéressant de placer le dossier temporaire en RAM plutôt que sur le disque dur. En plus d'accéler quelques traitements, cette méthode à également l'avantage de vider ce dossier à chaque boot. Pour ce faire, dans /etc/fstab, on ajoutera la ligne suivante :

none /tmp tmpfs defaults,nosuid,nodev,noexec 0 0


Il peut également être intéressant, pour ceux qui laissent leur machine allumée 24h/24, de placer une règle cron qui vide les fichiers temporaires à intervalle régulier, afin de ne pas encombrer la mémoire. La commande à mettre dans la tâche cron est la suivante :

find /tmp -type f -mmin +1440 -delete > /dev/null


Merci à Dek et au forum Gentoo francophone pour ces astuces

 
  • Placer la partie "vivante" de FireFox en RamDisk

Cette astuce fonctionne indépendamment de la précédente, mais mise en place conjointement, elle se complètent parfaitement. Il s'agit ici de limiter les accès au SSD par FireFox, sans pour autant perdre tout son profil à chaque boot. Ainsi, on aura besoin de rsync pour réaliser les synchronisation de données. Avec FireFox fermé, on commence par dupliquer .mozilla dans un second dossier qui servira de sauvegarde lorsque la machine sera éteinte et de source de restauration lorsque la machine sera allumée :

cp -r .mozilla .mozilla_ref


On monte en RamDisk le répertoire du profil FireFox :

none      /home/kortex/.mozilla         tmpfs           defaults,uid=1000,gid=100,mode=750     0 0


Ou on remplacera dans le chemin kortex par le nom de votre utilisateur, et où on s'assurera que les valeurs de uid et gid correspondent à celle de l'utilisateur et de son groupe principal.
Ensuite, dans les scripts s'exécutant au démarrage et à l'extinction de la machine, on synchronise le répertoire de référence (.mozilla_ref) et le répertoire normal (.mozilla). A l'allumage de la machine :

rsync -a /home/kortex/.mozilla_ref/ /home/kortex/.mozilla/


A l'extinction de la machine :

rsync -a /home/kortex/.mozilla/ /home/kortex/.mozilla_ref/


Dans mon cas, sous Arch, les fichiers à modifier sont /etc/rc.local et /etc/rc.local.shutdown, il faudra trouver ceux qui correspondent à votre distribution.
Merci à Dek pour cette astuce

Message cité 4 fois
Message édité par Kortex@HFR le 19-10-2010 à 18:59:42

---------------
Paisible, sous l'Arch - Mon feed
n°1134731
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 12-05-2009 à 15:06:24  profilanswer
 

IV. Recensement des utilisateurs de SSD sous Linux
 
[albator] : Samsung SLC 32 Go
Aiua : Crucial M225 64 Go
Az4zel : Intel X25-M G2 80 Go
Aznox : Intel X25-M V2 80Go
babajaga888 : Vertex 4 128 Go, Ubuntu
bronislas : Intel X25-V
Burn2 : SSD intel 520, Xubuntu 12.04
cactus : Crucial C300 128 Go
carrion crow : Crucial C300 128Go, Crucial M4 128 Go, ArchLinux
d@kn1ko : Crucial M4 64go, Xubuntu
Deadog : OCZ Vertex Turbo 30 Go
deK : Intel 520 120 Go, ArchLinux
dusty35 : Crucial M4 64 Go, Ubuntu 11.04
eccoh : Samsung 32Go SLC, Corsair X32
Flying-Chewbacca : Samsung P18000
grao : Crucial C300 64Go sous Ubuntu 11.10, OCZ vertex 4 256 Go sous debian Wheezy
hecube : Samsung SSD 830 Series, Ubuntu
Jadou2291 : Crucial M225 64 Go / Kingston SSDnow V-Series 40 Go / Mtron 3025 16 Go
kikiesttoujoursla : Crucial C300 64go, Debian Squeeze
Kortex@HFR : Crucial M4 512 Go, ArchLinux x86_64
Kytrix : Crucial C300 64 Go, Ubuntu 64Bits
krumli : Intel X25M Postville 160 Go  
lepcfou : Crucial M4 256 Go, Ubuntu  
l0g4n : Silicon Power 32Go
M300A : Transcend TS120GSSD25D-M 120Go
Mac Gyver 974 : Corsair Nova 32 Go, Gentoo
matthias : OCZ Vertex 2 60 Go, Ubuntu 11.04
memaster62 : CF Sandisk 12 et 8 Go
minux : Crucial M4, Samsung 840 Pro
muzah : Corsair F60
Morpheus86 : Crucial M4 64 Go, ArchLinux x86_64
Nossyfff :  OCZ Octane 128Go, Xubuntu 12.04 x86_64
opt : OCZ Vertex Turbo 60
Plam : Intel "Postville" X25-M 80 Go
punishthecat : OCZ Solid Series
s@r@v : Crucial M225 64 Go
Sagittarius : OCZ  Solid_SSD 32, Aspire One
sligor : Corsair Force GT 120 Go, Debian
Swiss_Knight : Crucial M4 128Go, Ubuntu
Sylfurd : Toshiba THNSNC128GMMJ 128 Go
thana54 : Kingston SSDNow M-Series 40Go (clone X25-M G2), OCZ Octane 128Go, Debian Sid amd64
The_K586 : SSD Asus 16Go
TNZ : OCZ Vertex 4 sous Ubuntu 13.04 64 bit (+ Firmware Redmondien V7 pour les jeux)
Vélo Love : Crucial M4 64 Go, OpenSUSE 12.1
whiterabbit : Intel 330 Series 180 Go, ArchLinux x86_64
zelogik : Intel X25-E 64Go et OCZ Core Series V2 120Go

Message cité 2 fois
Message édité par Kortex@HFR le 21-06-2013 à 08:08:40

---------------
Paisible, sous l'Arch - Mon feed
n°1134734
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 12-05-2009 à 15:21:03  profilanswer
 

Je commencerai en parlant, d'après ce que j'ai lu des fichiers temporaires.

 

Apparemment, on peut se permettre, si on dispose de suffisamment de RAM, de mettre /tmp en RAM pour ne pas utiliser inutilement le SSD. Pour cela, on doit passer par la modification de fstab, en ajoutant la ligne suivante :

 
Citation :

none /tmp tmpfs defaults,nosuid,nodev,noexec 0 0

 

Du coup, tout ce qui doit transiter par /tmp ne passe plus par le SSD, ce qui évite de l'user.
_____________________________________________________

 

On conseille régulièrement de ne pas utiliser ext3/ext4 à cause de la journalisation qui a tendance à créer pas mal de traffic, et d'en rester à ext2, non journalisé, pour les SSD.
_____________________________________________________

 

Que pensez-vous de ces astuces/conseils ? Sont-ils corrects, méritent-ils d'être dans le premier post ?


Message édité par Kortex@HFR le 12-05-2009 à 15:21:25

---------------
Paisible, sous l'Arch - Mon feed
n°1134737
deK
watching for beerz on the wing
Posté le 12-05-2009 à 15:30:14  profilanswer
 

Concernant la journalisation je me prendrais pas la tête.
 
En ayant lu plein de trucs là-dessus pour le SSD mon Aspire One, les algos de wear-levelling font en sorte que la durée de vie est assez grande, même en écrivant beaucoup sur le disque : je n'ai plus les chiffres en tête, mais c'est du genre 10 ans de durée de vie en écrivant chaque jour sur la moitié du SSD (ce que personne ne fait en utilisation classique).
 
Et la journalisation ben c'est quand même sympa en cas de crash, donc je dirais Ext3 ou Ext4, c'est vraiment sans risque.
(Ext4 je nuance un peu maintenant, j'ai été victime du symptôme des fichiers à 0 octets après un hard reset, donc j'aurais plutôt tendance à rester sur Ext3  :o )
 
Tourner sans journalisation, c'est vraiment pour des disques sans aucun mécanisme de wear-levelling, comme les cartes CF.
Un SSD récent est fait pour être utilisé quasiment comme un HDD classique.


---------------
blog :: Feed HA/V :: IN ARCH WE TRUST§§§          
n°1134742
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 12-05-2009 à 15:35:19  profilanswer
 

deK a écrit :

Concernant la journalisation je me prendrais pas la tête.
 
En ayant lu plein de trucs là-dessus pour le SSD mon Aspire One, les algos de wear-levelling font en sorte que la durée de vie est assez grande, même en écrivant beaucoup sur le disque : je n'ai plus les chiffres en tête, mais c'est du genre 10 ans de durée de vie en écrivant chaque jour sur la moitié du SSD (ce que personne ne fait en utilisation classique).
 
Et la journalisation ben c'est quand même sympa en cas de crash, donc je dirais Ext3 ou Ext4, c'est vraiment sans risque.
(Ext4 je nuance un peu maintenant, j'ai été victime du symptôme des fichiers à 0 octets après un hard reset, donc j'aurais plutôt tendance à rester sur Ext3  :o )
 
Tourner sans journalisation, c'est vraiment pour des disques sans aucun mécanisme de wear-levelling, comme les cartes CF.
Un SSD récent est fait pour être utilisé quasiment comme un HDD classique.


Voila déjà une première réponse intéressante concernant le type de système de fichier :)
 
J'attends d'autres avis, allez, allez ;)


---------------
Paisible, sous l'Arch - Mon feed
n°1134812
arghbis
salops de dauphins
Posté le 12-05-2009 à 20:34:58  profilanswer
 

j'ai utilisé du ext3 sur un ssd intel x25-m 80Go. Un reboot violent (electrique) a foutu le fs en rade. Alors qui incriminer? la faute à pas de chance? une faiblesse de ext3 (j'en doute)? le ssd?
 
enfin, ça m'inquiète un peu vu que ça va être pour un serveur, mais bon, on verra dans le temps.

n°1134887
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 08:08:11  profilanswer
 

@dek : j'aime bien la solution du RAMDisk pour le dossier ~/.mozilla, mais chez moi ça déconne un peu. Le fonctionnement est nickel, mais lors du shutdown, ça couille. A priori, le système tente de démonter le FS (/home) avant que rsync ait terminé. Du coup, FF pense qu'il s'est crashé en m'ouvre toujours la même session après un reboot. As-tu une idée ?
EDIT : laisse tomber, j'ai vidé mon profil .mozilla_ref, et tout fonctionne nickel, je sais pas ce qu'il y avait de pourri dedans, mais en tout cas ça empêchait le truc de fonctionner. Par contre j'ai toujours un message bizarre à l'arrêt de la machine : /dev/sda6 (mon /home) est occupé lors du démontage, que j'ai ou pas ajouté la ligne de ton astuce dans rc.local.shutdown. J'ai remarqué que cela ne se produit que si j'ai ouvert ma session graphique, un reboot un tty sans avoir ouvert une session graphique (juste KDM de lancé) ne pose pas de problème pour démonter /home.

Message cité 1 fois
Message édité par Kortex@HFR le 13-05-2009 à 09:00:32

---------------
Paisible, sous l'Arch - Mon feed
n°1134913
deK
watching for beerz on the wing
Posté le 13-05-2009 à 09:32:43  profilanswer
 

Kortex@HFR a écrit :


EDIT : laisse tomber, j'ai vidé mon profil .mozilla_ref, et tout fonctionne nickel, je sais pas ce qu'il y avait de pourri dedans, mais en tout cas ça empêchait le truc de fonctionner. Par contre j'ai toujours un message bizarre à l'arrêt de la machine : /dev/sda6 (mon /home) est occupé lors du démontage, que j'ai ou pas ajouté la ligne de ton astuce dans rc.local.shutdown. J'ai remarqué que cela ne se produit que si j'ai ouvert ma session graphique, un reboot un tty sans avoir ouvert une session graphique (juste KDM de lancé) ne pose pas de problème pour démonter /home.

 

Tu avais peut-être un peu trop de fichiers en cache offline ?
Aucune idée par contre pour ton problème de démontage :/

Message cité 1 fois
Message édité par deK le 13-05-2009 à 09:32:51

---------------
blog :: Feed HA/V :: IN ARCH WE TRUST§§§          
mood
Publicité
Posté le 13-05-2009 à 09:32:43  profilanswer
 

n°1134915
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 09:36:14  profilanswer
 

deK a écrit :


 
Tu avais peut-être un peu trop de fichiers en cache offline ?
Aucune idée par contre pour ton problème de démontage :/


D'ailleurs, en dehors de cette astuce pour le profil, que faut-il changer dans la conf de FF pour qu'il utilise le moins possible le disque dur ? Il me semble que tu parlais de cache offline/online, mais je ne retrouve plus l'info :/


---------------
Paisible, sous l'Arch - Mon feed
n°1134926
deK
watching for beerz on the wing
Posté le 13-05-2009 à 09:55:52  profilanswer
 

Tu vas sur la page "about:config" et tu filtres avec le mot-clé "browser.cache", là tu as tous les settings en rapport avec le cache, online et offline.

 

Mais à savoir que si tu utilises l'astuce du .mozilla en ram, ainsi que le /tmp en tmpfs, FF ne se servira jamais du disque, même le cache offline sera stocké en ram (d'où mon conseil de vérifier la taille qui lui est allouée pour ne pas remplir la ram).
Ben oui, avec FF, tout est stocké soit dans /tmp (pas grand chose, par exemple les streams flash) soit dans .mozilla/ .

 

Les écritures sur le disque ne se feront qu'au shutdown, avec un rsync.
(tu peux également placer le rsync dans un cron si tu veux synchroniser régulièrement)

 

Pour récapituler :
cache online -> RAM
cache offline -> HDD (.mozilla)
base de données sqlite -> HDD (.mozilla)
bordel genre cookies et compagnie -> HDD (.mozilla)
certains fichiers temporaires -> HDD (/tmp)

 

En définissant des tmpfs pour /tmp et .mozilla on place tout en ram au final.

 

Message cité 1 fois
Message édité par deK le 13-05-2009 à 10:00:37

---------------
blog :: Feed HA/V :: IN ARCH WE TRUST§§§          
n°1134941
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 10:32:17  profilanswer
 

deK a écrit :

Tu vas sur la page "about:config" et tu filtres avec le mot-clé "browser.cache", là tu as tous les settings en rapport avec le cache, online et offline.
 
Mais à savoir que si tu utilises l'astuce du .mozilla en ram, ainsi que le /tmp en tmpfs, FF ne se servira jamais du disque, même le cache offline sera stocké en ram (d'où mon conseil de vérifier la taille qui lui est allouée pour ne pas remplir la ram).
Ben oui, avec FF, tout est stocké soit dans /tmp (pas grand chose, par exemple les streams flash) soit dans .mozilla/ .
 
Les écritures sur le disque ne se feront qu'au shutdown, avec un rsync.
(tu peux également placer le rsync dans un cron si tu veux synchroniser régulièrement)
 
Pour récapituler :
cache online -> RAM
cache offline -> HDD (.mozilla)
base de données sqlite -> HDD (.mozilla)
bordel genre cookies et compagnie -> HDD (.mozilla)
certains fichiers temporaires -> HDD (/tmp)
 
En définissant des tmpfs pour /tmp et .mozilla on place tout en ram au final.
 


OK, merci, c'est parfait :)


---------------
Paisible, sous l'Arch - Mon feed
n°1134970
thana54
made in concept
Posté le 13-05-2009 à 12:22:10  profilanswer
 

CF de 4Go ici et en ext3 [:chrisbk]
Quelques tmpfs de rigueur (debian)

Code :
  1. tmpfs /tmp tmpfs defaults 0 0
  2. tmpfs /var/cache/apt/archives tmpfs rw 0 0


Création automatique du dossier /var/cache/apt/archives/partial via un script init.d (runlevel 2,3,4,5)


---------------
[ Nvidia ] Le topic des drivers sur OSA | [Geeksphone] One, Zero, les smartphones libres | [Unique] Nettops HD, tout piti mais costaud
n°1134972
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 13:02:15  profilanswer
 

thana54 a écrit :

CF de 4Go ici et en ext3 [:chrisbk]
Quelques tmpfs de rigueur (debian)

Code :
  1. tmpfs /tmp tmpfs defaults 0 0
  2. tmpfs /var/cache/apt/archives tmpfs rw 0 0


Création automatique du dossier /var/cache/apt/archives/partial via un script init.d (runlevel 2,3,4,5)


C'est rigolo, j'y pensais à midi, je me disais qu'avoir un tmpfs pour le cache du gestionnaire de paquets était peut être une bonne idée après l'installation de la distrib (où traditionnellement, on télécharge beaucoup). Du coup, je vais peut être le faire pour mon install sous Arch.


---------------
Paisible, sous l'Arch - Mon feed
n°1134975
thana54
made in concept
Posté le 13-05-2009 à 13:07:00  profilanswer
 

Ca dépend de la ram disponible. Pour moi ca va, j'ai un petit 1.5Go de libre, mais pour les petites config, ca peut faire mal un dl après installation.


---------------
[ Nvidia ] Le topic des drivers sur OSA | [Geeksphone] One, Zero, les smartphones libres | [Unique] Nettops HD, tout piti mais costaud
n°1134976
deK
watching for beerz on the wing
Posté le 13-05-2009 à 13:11:27  profilanswer
 

Kortex@HFR a écrit :


C'est rigolo, j'y pensais à midi, je me disais qu'avoir un tmpfs pour le cache du gestionnaire de paquets était peut être une bonne idée après l'installation de la distrib (où traditionnellement, on télécharge beaucoup). Du coup, je vais peut être le faire pour mon install sous Arch.


 
Je le fais sur mon netbook sous Arch, j'ai simplement spécifié l'emplacement du cache dans la config de yaourt vers /tmp/yaourt_cache, mon /tmp étant en tmpfs  ;)  
 
Yaourt m'insulte seulement parce qu'il ne trouve plus l'ancien cache et doit donc le recréer, mais rien de plus.
Effectivement, ça pose le problème lors de grosses updates, ne pas oublier de nettoyer le cache après.


---------------
blog :: Feed HA/V :: IN ARCH WE TRUST§§§          
n°1134980
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 14:10:26  profilanswer
 

Dek, si tu as une seconde, peux-tu contrôler les informations que j'ai mise dans les premiers posts, notamment dans la partie III. Conseils et astuces. Les deux viennent de toi, au moins en partie, j'aimerais avoir ton aval que tout est correct. Merci d'avance :hello:


---------------
Paisible, sous l'Arch - Mon feed
n°1134986
deK
watching for beerz on the wing
Posté le 13-05-2009 à 14:26:14  profilanswer
 

Pour la première partie, je trouve ça très très bien  :jap:  
 
Juste une petite faute à wear-levelling  :o  
(il y en a peut-être d'autres, j'ai juste noté celle-ci en lisant rapidement)
Et pour les perfs des SSD haut de gamme, il y a encore plus fort  ;)  
 
Pour le reste c'est parfait, et je te colle mon script d'init pour Debian (qui réalise la même chose que les /etc/rc.local.x mais pallie l'absence de rc.local.shutdown sous Debian) :
 

#! /bin/sh
# /etc/init.d/FFram
#
 
case "$1" in
  start)
    echo "FFram : synchro disque->RAM"
    rsync -a --delete /home/dek/.mozilla_ref/ /home/dek/.mozilla/
    ;;
  stop)
    echo "FFram : synchro RAM->disque"
    rsync -a --delete /home/dek/.mozilla/ /home/dek/.mozilla_ref/
    ;;
  *)
    echo "Usage: /etc/init.d/FFram {start|stop}"
    exit 1
    ;;
esac
 
exit 0


 
Pas raffiné, mais il fonctionne  :D  
 
Sinon un petit lien "Sujets à lire" vers ce topic peut être de bon aloi, on y traite également de ces questions :
http://forum.hardware.fr/hfr/OSAlt [...] 9104_1.htm
 
Et je viens de me rappeller de cette discussion : http://forum.hardware.fr/hfr/OSAlt [...] 7924_1.htm


---------------
blog :: Feed HA/V :: IN ARCH WE TRUST§§§          
n°1134988
thana54
made in concept
Posté le 13-05-2009 à 14:31:33  profilanswer
 

Kortex@HFR a écrit :

III. Conseils et astuces pour optimiser son SSD
 

  • Placer la dossier temporaire en RamDisk

Afin de limiter les accès au SSD et ainsi éviter les lectures/écritures inutiles, il est intéressant de placer le dossier temporaire en RAM plutôt que sur le disque dur. En plus d'accélerer quelques traitements, cette méthode à également l'avantage de vider ce dossier à chaque boot. Pour ce faire, dans /etc/fstab, on ajoutera la ligne suivante :


Le ramdisk est un peu dépassé il me semble, et tmpfs est plus souple (et permet aussi de modifier la taille allouée en ram plus simplement).
Le vidage de la partition en tmpfs se fait au démontage de celle-ci, et non au boot. On pourrait croire que la ram du pc agit comme un SSD quand il est éteins, mais non. La ram (hors mode veille spécifique) ne garde pas les données qu'elle contient en cas de coupure de courant.
 
Pour le blabla sur les SSD, il y a un topic en cat hardware ( [Topic Unique] FFD (Fast Flash Disk)/ SSD, pas si loin de nous).


---------------
[ Nvidia ] Le topic des drivers sur OSA | [Geeksphone] One, Zero, les smartphones libres | [Unique] Nettops HD, tout piti mais costaud
n°1134989
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 14:32:57  profilanswer
 

deK a écrit :

Pour la première partie, je trouve ça très très bien  :jap:  
 
Juste une petite faute à wear-levelling  :o  
(il y en a peut-être d'autres, j'ai juste noté celle-ci en lisant rapidement)
Et pour les perfs des SSD haut de gamme, il y a encore plus fort  ;)  
 
Pour le reste c'est parfait, et je te colle mon script d'init pour Debian (qui réalise la même chose que les /etc/rc.local.x mais pallie l'absence de rc.local.shutdown sous Debian) :
 

#! /bin/sh
# /etc/init.d/FFram
#
 
case "$1" in
  start)
    echo "FFram : synchro disque->RAM"
    rsync -a --delete /home/dek/.mozilla_ref/ /home/dek/.mozilla/
    ;;
  stop)
    echo "FFram : synchro RAM->disque"
    rsync -a --delete /home/dek/.mozilla/ /home/dek/.mozilla_ref/
    ;;
  *)
    echo "Usage: /etc/init.d/FFram {start|stop}"
    exit 1
    ;;
esac
 
exit 0


 
Pas raffiné, mais il fonctionne  :D  
 
Sinon un petit lien "Sujets à lire" vers ce topic peut être de bon aloi, on y traite également de ces questions :
http://forum.hardware.fr/hfr/OSAlt [...] 9104_1.htm
 
Et je viens de me rappeller de cette discussion : http://forum.hardware.fr/hfr/OSAlt [...] 7924_1.htm


Putain les prix des SSD chez G-Monster-Promise... Bon, on est clairement chez le professionnel par contre, d'autant plus que ça doit être plus ou moins à base de RAID ou quelque chose du genre pour atteindre ces débits. Ca sort un peu du cadre de ce topic je trouve, mais bon, je vais quand même en faire mention :)
 
Pour le reste, merci d'avoir pris le temps de relire et de linker quelques sujets et tout ça, ça aide à faire avancer le topic :)


---------------
Paisible, sous l'Arch - Mon feed
n°1134990
thana54
made in concept
Posté le 13-05-2009 à 14:35:28  profilanswer
 

Avant que je n'oublie, j'utilise sidux (debian sid avec un kernel spécifique adapté aux SSD). Si vous avez quelques pistes pour vérifier des réglages spécialements dédiés aux SSD, je suis preneur :jap: (sur le papier ca fait beau, mais je ne sais pas si c'est vraiment en place et fonctionnel).

Message cité 1 fois
Message édité par thana54 le 13-05-2009 à 14:35:58

---------------
[ Nvidia ] Le topic des drivers sur OSA | [Geeksphone] One, Zero, les smartphones libres | [Unique] Nettops HD, tout piti mais costaud
n°1134991
deK
watching for beerz on the wing
Posté le 13-05-2009 à 14:40:22  profilanswer
 

thana54 a écrit :


Le ramdisk est un peu dépassé il me semble, et tmpfs est plus souple (et permet aussi de modifier la taille allouée en ram plus simplement).
Le vidage de la partition en tmpfs se fait au démontage de celle-ci, et non au boot.  


 
Le terme RamDisk est un abus de langage ici, si tu regardes bien la méthode fait appel à tmpfs ;)
 

Kortex@HFR a écrit :


Putain les prix des SSD chez G-Monster-Promise... Bon, on est clairement chez le professionnel par contre, d'autant plus que ça doit être plus ou moins à base de RAID ou quelque chose du genre pour atteindre ces débits. Ca sort un peu du cadre de ce topic je trouve, mais bon, je vais quand même en faire mention :)


 
À mon avis ça va arriver assez vite (le principe, pas ce SSD-là) chez les particuliers, placer le SSD sur PCI-E directement ça ne coûte pas vraiment beaucoup plus cher (contrôleur différent, simplement), et le potentiel en perfs est énormes.
Le seul écueil aux dernières nouvelles, c'est de pouvoir booter dessus.
Mais ça va être dispo plus vite chez les linuxiens que les windowsiens ça je pense  :D


---------------
blog :: Feed HA/V :: IN ARCH WE TRUST§§§          
n°1134993
thana54
made in concept
Posté le 13-05-2009 à 14:48:01  profilanswer
 

deK a écrit :


 
Le terme RamDisk est un abus de langage ici, si tu regardes bien la méthode fait appel à tmpfs ;)
 


Autant clarifier les choses dés le début oui.


---------------
[ Nvidia ] Le topic des drivers sur OSA | [Geeksphone] One, Zero, les smartphones libres | [Unique] Nettops HD, tout piti mais costaud
n°1135006
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 15:24:51  profilanswer
 

thana54 a écrit :

Avant que je n'oublie, j'utilise sidux (debian sid avec un kernel spécifique adapté aux SSD). Si vous avez quelques pistes pour vérifier des réglages spécialements dédiés aux SSD, je suis preneur :jap: (sur le papier ca fait beau, mais je ne sais pas si c'est vraiment en place et fonctionnel).


Ce que j'aimerais savoir le plus vote possible, c'est comment partitionner et formater son SSD avec les partition alignée, bonne taille de bloc, etc...
 
Si quelqu'un a une méthode infaillible avec des outils libres, je suis preneur...


---------------
Paisible, sous l'Arch - Mon feed
n°1135007
thana54
made in concept
Posté le 13-05-2009 à 15:26:04  profilanswer
 

Déjà, ne pas faire de swap :o
 
A moins de vouloir cramer le SSD si la machine swap déjà bien d'habitude.
 
Mais c'est marrant de voir toute la ram occupée et de perdre le contrôle de la machine :whistle:


---------------
[ Nvidia ] Le topic des drivers sur OSA | [Geeksphone] One, Zero, les smartphones libres | [Unique] Nettops HD, tout piti mais costaud
n°1135010
deK
watching for beerz on the wing
Posté le 13-05-2009 à 15:28:51  profilanswer
 

thana54 a écrit :

Déjà, ne pas faire de swap :o
 
A moins de vouloir cramer le SSD si la machine swap déjà bien d'habitude.
 
Mais c'est marrant de voir toute la ram occupée et de perdre le contrôle de la machine :whistle:


 
Boarf c'est un peu pareil, avec le wear-levelling, si le swap n'est utilisé qu'occasionnellement, pas de problème, les écritures ne seront jamais faites sur les mêmes secteurs.
Et sans swap, pas d'hibernation.
Évidemment, si le swap est utilisé constamment, là ça peut devenir moins cool.


---------------
blog :: Feed HA/V :: IN ARCH WE TRUST§§§          
n°1135015
cactus
Posté le 13-05-2009 à 16:06:55  profilanswer
 

[:blueflag]  
(j'ai vu l'appel dans le topic OCZ... tu devrais y mettre le lien d'ailleurs ! ;) )

n°1135016
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 13-05-2009 à 16:17:12  profilanswer
 

cactus a écrit :

[:blueflag]
(j'ai vu l'appel dans le topic OCZ... tu devrais y mettre le lien d'ailleurs ! ;) )


Certes, je le fait de suite :)

 

Sinon, j'ai ajouté un petit texte sur le choix du FS pour utiliser un SSD. Si vous avez des critiques à y faire, merci de poster et de proposer les modifications à apporter, histoire d'être le plus précis possible.

 

Edit :
D'ailleurs, un peu tout le monde, merci de me préciser la référence exact de votre SSD pour le recensement, ce sera d'autant plus précis.


Message édité par Kortex@HFR le 13-05-2009 à 16:20:03

---------------
Paisible, sous l'Arch - Mon feed
n°1135017
thana54
made in concept
Posté le 13-05-2009 à 16:21:23  profilanswer
 

Pour moi CF Transcend 300x 4Go branchée sur adaptateur CF-SATA (cherchez sur la bay le modèle rouge qui est décris comme plus rapide que le modèle bleu), j'hésite à me prendre une chinoise de 16Go en 300x, les 4Go sont un peu juste en utilisation desktop.

Message cité 1 fois
Message édité par thana54 le 13-05-2009 à 16:22:16

---------------
[ Nvidia ] Le topic des drivers sur OSA | [Geeksphone] One, Zero, les smartphones libres | [Unique] Nettops HD, tout piti mais costaud
n°1135121
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 14-05-2009 à 10:03:44  profilanswer
 

Avant de mettre ceci dans les premiers posts, j'aimerais avoir votre avis (cela concerna l'alignement des partitions) :
http://www.ocztechnologyforum.com/ [...] tcount=134
C'est assez convaincant, et ça reste très simple en plus je trouve, non ? C'est uniquement basé sur fdisk, ce qui reste quand même très tranquille.


---------------
Paisible, sous l'Arch - Mon feed
n°1135165
[Albator]
MDK un jour, MDK toujours !
Posté le 14-05-2009 à 13:40:01  profilanswer
 

Salut,
 
j'utilise pour ma part un SSD également (Samsung SLC 32 Go, j'ai oublié la réf exacte), j'ai aligné les partitions, et je ressens une amélioration des perfs.
Je vous fais part de mes réflexions.
 
Edit: Je précise qu'utiliser une feinte comme forcer fdisk à utiliser une taille de piste de 56 secteurs (fdisk -s 56 ...) n'est (à mon avis) pas du tout satisfaisant car:
- L'alignement est réalisé sur une taille de 4 Ko, alors qu'un SSD utilise (à priori) une taille de bloc de 64 Ko voire 128 Ko (à confirmer par les pros du hardware).
- Cette méthode ne tient pas compte du "décalage initial" imposé par MBR/Table des partitions en début de disque (voir plus loin).
/Fin Edit
 
Le plus gros problème pour aligner c'est que la gestion des partitions avec fdisk va se baser sur une "géométrie" de disque dur qui est virtuelle (cylindres, têtes, secteurs). Cette géométrie ne correspond à rien de réel et peut varier.
1) La seule donnée qui est toujours constante, c'est la taille d'un secteur: 512 octets. Il faut exploiter cette information et partitionner en comptant les secteurs.
2) Avec une table des partitions standard (msdos), le premier secteur (numéro 0) contient obligatoirement le MBR et la table des partitions. Si on ne le spécifie pas, la première partition commence au secteur numéro 1. Il faut tenir compte de ce décalage.
3) Il faut connaitre à l'avance la taille de bloc sur laquelle on souhaite s'aligner. Sur un SSD, la plupart des forums indiquent que cette taille est 128 Ko. Je n'ai aucune information sûre à ce sujet.
 
 
A partir de ces 3 éléments, on en déduit que:
1) La taille d'un bloc SSD, mesurée en secteurs, est de 256 (128 Ko / 512 o)
2) Pour aligner les partitions, il faudra que chaque début de partition commence à un secteur multiple de 256.
3) A cause de la table des partitions/MBR, la première partition devra commencer au secteur 256 (le secteur 0 est réservé, les secteurs 1 à 255 seront intentionnellement laissés inoccupés. Espace gaspillé: 255 secteurs = 127.5 Ko)
 
Supposons que je veuille partitionner comme suit (fictif):
/dev/sda1                 500 Mo
/dev/sda2                 2000 Mo
/dev/sda3                 10000 Mo
/dev/sda4                 3000 Mo
 
On calcule les tailles des partitions, en secteurs de 512 octets:
/dev/sda1      500 Mo = 500 * 1024 * 1024 / 512 = 1024000 secteurs
/dev/sda2      2000 Mo = 2000 * 1024 * 1024 / 512 = 4096000 secteurs
/dev/sda3      10000 Mo = 10000 * 1024 * 1024 / 512 = 20480000 secteurs
/dev/sda4      3000 Mo = 3000 * 1024 * 1024 / 512 = 6144000 secteurs
 
On calcule le positionnement des partitions sur le SSD. Il faut trouver le secteur de début et le secteur de fin:
/dev/sda1    début: 256       Fin: 256 + 1024000 - 1 = 1024255
/dev/sda2    début: 1024255 + 1 = 1024256         Fin: 1024256 + 4096000 - 1 = 5120255
/dev/sda3    début: 5120255+ 1 = 5120256      Fin: 5120256 + 20480000 - 1 = 25600255
/dev/sda4    début: 25600255+ 1 = 25600256     Fin: 24678456 + 6144000 - 1 = 31744255
 
Maintenant je connais la position des partitions.
On attaque le partitionnement avec Parted (en supposant que le SSD est au préalable vierge), qui permet de spécifier secteur de début/fin pour chaque partition:

Code :
  1. # parted
  2. (parted) unit s
  3. (parted) mkpart primary 256 1024255
  4. (parted) mkpart primary 1024256 5120255
  5. (parted) mkpart primary 5120256 25600255
  6. (parted) mkpart primary 25600256 31744255
  7. (parted) q


 
Me voila avec des partitions alignées à 128 Ko.
Si vous utilisez fdisk pour visualiser les partitions, il va se plaindre que les fins de partitions ne correspondent pas à une limite de cylindre. Il faut ignorer cet avertissement (et ne plus utiliser fdisk).
 
 
Maintenant, il faut formatter les partitions.
Il existe (au moins dans EXT2/3/4 et dans XFS) la possibilité de spécifier un "stride size", paramètre normalement utilisé dans le cas de grappe RAID, où la notion d'alignement est aussi importante.
On peut ainsi optimiser le filesystem pour un alignement donné.
 
Issu de la page de man mkfs.ext4:

Citation :

stride=stride-size
                          Configure the  filesystem  for  a  RAID  array  with
                          stride-size filesystem blocks. This is the number of
                          blocks read or written to disk before moving to  the
                          next  disk,  which  is  sometimes referred to as the
                          chunk  size.   This  mostly  affects  placement   of
                          filesystem  metadata  like bitmaps at mke2fs time to
                          avoid placing them on a single disk, which can  hurt
                          performance.  It may also be used by the block allo‐
                          cator.


 
En EXT2/3/4, la taille d'un Stride est exprimée en nombre de blocs du filesystem (rien à voir avec la taille de blocs du SSD).
Normalement un bloc EXT2/3/4 a toujours une taille de 4 Ko (sauf sur les partitions de très petite taille). On peut forcer cette taille avec le paramètre -b 4096 .
 
Pour réaliser un formattage aligné au SSD, il faut compter la taille d'un bloc SSD (128 Ko) en nombre de blocs EXT (4 Ko).
Résultat: 128 / 4 = 32
 
On va donc formatter comme suit:
# mkfs.ext4 -b 4096 -E stride=32 /dev/sda1
 
 
Avec XFS, les paramètres sont différents mais le principe est inchangé.
 
Extrait du man mkfs.xfs:

Citation :

sunit=value
                          This is used to specify the stripe unit for  a  RAID
                          device  or  a  logical  volume.  The value has to be
                          specified in 512-byte block units. Use the su subop‐
                          tion  to specify the stripe unit size in bytes. This
                          suboption ensures  that  data  allocations  will  be
                          stripe  unit aligned when the current end of file is
                          being extended and the  file  size  is  larger  than
                          512KiB.  Also inode allocations and the internal log
                          will be stripe unit aligned.


 
Avec un bloc XFS = 4 Ko
Le "sunit" est la taille du bloc SSD exprimée en secteurs de 512 octets.
Donc: 128 Ko = 256 secteurs de 512 octets
 
La commande est donc:  (option -d pour la partie DATA et -l pour la partie LOG du filesystem)
# mkfs.xfs -b 4096 -d sunit=256 -l sunit=256 /dev/sda1
 
 
 
Par ailleurs, je me suis aperçu en installant Mandriva 2009.1 Spring, que DiskDrake, en passant en mode "Expert", permet de spécifier le "secteur de début" des partitions, et la taille des partitions en méga-octets.
En créant la première partition au secteur 256, puis en créant les autres de n'importe quelle taille (exprimée en Méga-Octets indivisibles), je vais obtenir naturellement un alignement à 128 Ko pour les partitions.
Reste le problème du formattage aligné, qui n'est pas pris en compte par DiskDrake (à ma connaissance).


Message édité par [Albator] le 14-05-2009 à 21:09:18
n°1135172
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 14-05-2009 à 14:28:20  profilanswer
 

Bordel... C'est vraiment pas simple leur affaire... Je pense qu'il va falloir que je relise une fois ou deux ton post pour essayer de tout comprendre. Le truc, c'est que j'aimerais bien ne pas avoir à m'y prendre en 18 fois pour installer mon SSD (qui devrait arriver dans les prochains jour), donc j'aimerais réaliser un partitionnement aligné du premier coup. Je vais essayer de reprendre ton post et de l'adapter à mon futur Vertex 120Go. J'avoue que je patauge un peu avec ces conneries...
En tout cas, merci pour ce post très instructif :) J'espère pouvoir en faire un genre de règle absolu à mettre dans les premiers posts pour que tout le monde puisse en profiter.


Message édité par Kortex@HFR le 14-05-2009 à 14:29:05

---------------
Paisible, sous l'Arch - Mon feed
n°1135180
memaster62
just do turbo S and tux
Posté le 14-05-2009 à 14:50:27  profilanswer
 

thana54 a écrit :

Pour moi CF Transcend 300x 4Go branchée sur adaptateur CF-SATA (cherchez sur la bay le modèle rouge qui est décris comme plus rapide que le modèle bleu), j'hésite à me prendre une chinoise de 16Go en 300x, les 4Go sont un peu juste en utilisation desktop.


super ce topic :hello:  
moi j'ai 2x CF sandisk (une en 12Go ultra3 pour le / et une en 8Go ultra2 pour le /home)
ça fonctionne du tonnerre ;)  (2go de ram pour être à l'aise / noswap, tmpfs, noatime et syslog down)


---------------
ma conduite intérieure .:R | ...des ch'tis restos...
n°1135190
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 14-05-2009 à 15:08:26  profilanswer
 

[albator], excuse moi, mais il y a quelque chose que je ne comprend pas très bien... Je reprends dans ton post :

Citation :

A partir de ces 3 éléments, on en déduit que:
1) La taille d'un bloc SSD, mesurée en secteurs, est de 256 (128 Ko / 512 o)
2) Pour aligner les partitions, il faudra que chaque début de partition commence à un secteur multiple de 256.
3) A cause de la table des partitions/MBR, la première partition devra commencer au secteur 256 (le secteur 0 est réservé, les secteurs 1 à 255 seront intentionnellement laissés inoccupés. Espace gaspillé: 255 secteurs = 127.5 Ko)


Puis un peu plus loin, le tableau des partitions avec les secteurs :

Citation :

On calcule le positionnement des partitions sur le SSD. Il faut trouver le secteur de début et le secteur de fin:
/dev/sda1    début: 256       Fin: 256 + 1024000 - 1 = 1024255
/dev/sda2    début: 1024255 + 1 = 1024256         Fin: 102456 + 4096000 - 1 = 4198455
/dev/sda3    début: 4198455 + 1 = 4198456         Fin: 4198456 + 20480000 - 1 = 24678455
/dev/sda4    début: 24678455 + 1 = 24678456      Fin: 24678456 + 6144000 - 1 = 30822455


Or les chiffres en gras, divisés par 256 donnent des résultats non entiers, à savoir respectivement 16400.21875 et 96400.21875. J'ai loupé un épisode ? J'ai juste rien compris ? Ou il y a une erreur dans ton raisonnement ?

 

EDIT : laisse tomber, j'ai trouvé le problème : tu as fait une faute de frappe dans l'addition de calcul de la fin de sda2 que tu as reprise sur toute la suite :D Tu as noté 102456 au lieu de 1024256. Et forcément ça change tout...

 

Re-Edit :
l'utilisation d'une partition étendue et de lecteurs logiques a-t-elle une influence quelquonque sur le calcul des secteurs ?

 

Re-re-Edit :
Apparemment, oui, ça change des choses. Je n'ai pas pu créer des lecteurs logiques avec les tailles exactes sur un disque de test alors que les même partitions en primaires passent sans soucis.


Message édité par Kortex@HFR le 14-05-2009 à 16:12:00

---------------
Paisible, sous l'Arch - Mon feed
n°1135213
Kortex@HFR
Qu'ils sont cons ces lamas !!!
Posté le 14-05-2009 à 16:34:19  profilanswer
 

En me basant sur la méthode de [albator], je me suis fait un petit tableau sous OOo.Calc qui permet de calculer simplement, à partir de la taille souhaitée des partitions, les secteurs de début et de fin. Si il s'avère que cette méthode est une bonne méthode pour créer des partitions alignées sous Linux (pour l'instant elle me semble très bonne, mais j'aimerais être certain avant de mettre tout ça dans le premier post, etc, et notamment avoir l'avais d'autres personnes qui se sont penchées sur l'alignement), je diffuserai le tableau dans les premiers posts :)


---------------
Paisible, sous l'Arch - Mon feed
n°1135234
[Albator]
MDK un jour, MDK toujours !
Posté le 14-05-2009 à 19:07:56  profilanswer
 

Ouaip, j'ai fait tous les calculs de visu (pas en copiant/collant ma conf réelle), donc erreur potentielle. J'ai corrigé à nouveau de tête, normalement c'est bon.
En tout cas tu as raison, il est facile de vérifier la position de début de chaque partition en faisant simplement la division par 256.
 
Pour la partition étendue, à priori, son point de départ et de fin n'ont pas d'importance.
Ce sont les lecteurs logiques à l'intérieur de la partition étendue qui doivent être alignés, si c'est possible (pas testé). On doit pouvoir placer un "vide" de secteurs au début de la partition étendue pour que le 1er lecteur logique soit aligné, comme on l'a fait en début de disque.

Message cité 1 fois
Message édité par [Albator] le 14-05-2009 à 19:13:04
n°1135249
quess
Posté le 14-05-2009 à 21:17:40  profilanswer
 

drapal


---------------
---- Mon feedback ----
n°1135288
flying-che​wbacca
What has been seen...
Posté le 15-05-2009 à 01:39:14  profilanswer
 

J'ai un SSD Samsung P18000 quelque chose (le modèle Samsung des AOne) 8Go, formaté en ext4.
 
Il y a un naigateur plus léger qui écrit moins sur le disque (enfin je trouve), c'est Opera.
 
Mais le /tmp en tmpfs augmente en effet la rapidité générale

n°1135627
gui42
Posté le 16-05-2009 à 19:19:16  profilanswer
 

Très intéressant ça. Je pense justement un de ces moments à remplacer le HDD de mon portable. Donc merci.
- Petite question, le TRIM est supporté à partir de quelle version du noyau ?
- relis le paragraphe III désactiver le logging, il manque "plupart" au début.
Bonne soirée à tous

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  39  40  41  42  43  44
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  Hardware

  [Topic Unik] Les SSD sous Linux : recensement, optimisation, conseils

 

Sujets relatifs
Le mode pivot ou portrait sous Linux - écran verticalXdefaults, xinit, screenrc, bashrc : le topic des configs chiantes
Cherche distribution GNU/Linux ou autre (BSD,etc) pour netbookProblème Boot Linux et partition invisible
Dawn Small Linux et autre light distro.installation de protocoles sur un linux embarqué
Je quitte windows pour LinuxY a t-il un logiciel Linux capable de découper un fichier PDF via SH ?
Aide analyse de la commande top sous linuxCopier des dossiers de win2003 vers linux en gardant les droits NTFS
Plus de sujets relatifs à : [Topic Unik] Les SSD sous Linux : recensement, optimisation, conseils



Copyright © 1997-2014 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Avis LDLC / LesNumeriques.com