# [ssd] Optimisation i/o questions /var et cache XDG[résolu]

## gglaboussole

Bonjour et bonne année à tous   :Wink: 

Je viens de faire l'acquisition d'un disque SSD corsair et, en suivant quelques tutos pour minimiser les écritures sur le disque, j'ai 

déporté mon ~/.cache en RAM et monté /var, /usr/portage, ccache et le swap sur un HDD. 

/tmp est par défaut en tmpfs depuis que je suis passé à systemd et j'avais déjà monté depuis longtemps /var/tmp/portage en tmpfs ( je dispose de 12 GO de RAM)

J'ai deux petites questions :

1) J'ai lu partout que depuis quelques temps  il n'était plus possible sans initramfs d'avoir /usr et /var sur une partition séparée... or j'ai tenté cache pistache de le faire pour /var, sans initramfs, et je ne rencontre aucun problème particulier.... pourquoi ? Ce souci est il corrigé depuis peu, ou j'ai loupé un truc ?

2)Pour le .cache de mon répertoire pesronnel j'ai suivi un tuto ARCH et j'ai crée un fichier /etc/env.d/30xdg-data-local qui comporte :

```

XDG_CACHE_HOME="/tmp/.cache"

XDG_DATA_DIRS="/usr/local/share"

COLON_SEPARATED="XDG_DATA_DIRS XDG_CONFIG_DIRS"

```

Or j'ai plusieurs sessions qui peuvent être ouvertes en même temps sur mon pc ... du coup je me demande s'il ne peut pas y avoir collusion des répertoires .cache dans /tmp (entre mon /tmp/.cache et celui de ma fille par exemple...)

Y a t'il un moyen simple pour que ce répertoire devienne /tmp/~/.cache,  /~ le nom du répertoire personnel de l'utilisateur ?

(en clair que que .cache soit encapsulé dans un répertoire au nom de l'utilisateur au lieu d'être à la racine de /tmp pour éviter tout écrasement des données du cache)

J'ai tenté de le préfixer de ~/ dans ce fichier d'environnement mais il me créer litteralement un réperoire  ~   :Sad: 

Merci d'avance pour vos réponses...

----------

## El_Goretto

A ma connaissance, pour le 1/, c'est quand /usr est sur une partition dédiée, pas /var (je ne vois pas trop ce qu'il pourrait y avoir dessus de nécessaire à la phase initiale de boot).

----------

## k-root

 *gglaboussole wrote:*   

> 
> 
> 2)Pour le .cache de mon répertoire pesronnel j'ai suivi un tuto ARCH et j'ai crée un fichier /etc/env.d/30xdg-data-local qui comporte :
> 
> ```
> ...

 

 *http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html wrote:*   

> $XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used. 

 

oui c'est pas tres bon .. la bonne nouvelle c'est que les fichier sont en 700  .. c'est au programme de se débrouiller avec le fichier qui existe deja  (firefox, chrome, mail , keyring, you name it ... ) 

une solution bien plus simple , c'est de passer par .xprofile ou de rajouter un fichier dans /etc/X11/xinit/xinitrc.d/  , exemple : 15-xdg-data-gnome

cf : https://wiki.archlinux.org/index.php/Xprofile

voici le contenu d'un .xprofile qui fait ce que tu demande :

```
export XDG_CACHE_HOME=/tmp/$USER/.cache
```

si pas besoin de xorg alors avec .bash_login : http://unix.stackexchange.com/questions/57658/how-to-utilize-xdg-directories-and-paths-in-bash

----------

## gglaboussole

Merci beaucoup à vous 2 pour vos réponses ! Ton indication était parfaite k-root pour le .cache merci   :Very Happy: 

----------

## gglaboussole

L'astuce de k-root a très bien fonctionnée du 20/01 au 05/02.... je constate que le .cache est réapparu dans  mon home à cette date...

Le fichier /etc/X11/xinit/xinitrc.d/15-xdg-data-gnome est toujours présent, mais la déclaration XDG_CACHE_HOME=/tmp/$USER/.cache

 n'est plus prise en compte...

----------

## gglaboussole

Je viens de remettre XDG_CACHE_HOME="/tmp/.cache" dans  /etc/env.d/30xdg-data-local... ça ne marche plus non plus... je poursuis mes investigations...

----------

## gglaboussole

 :Idea:   Après analyse de mes log d'emerge (mise à jour de systemd le 05/02) et consultation des changelog (avec des références à  XDG_RUNTIME_DIR....) je crois 

que j'ai un bon suspect....

Je n'ai pas le temps d'ici ce week end mais je vais tenter un downgrade de systemd, et si mes soupçons sont avérés je ferai un rapport de bug et un retour sur ce post...  :Wink: 

Edit: Fausse piste et truc de fou... .cache est revenu tout seul dans /tmp/jerome/.....   :Shocked:   :Shocked: , du coup j'ai rebooté une bonne dizaine de fois... et plus de problème ( et j'ai fait aucun emerge depuis !) j'y comprends rien

Edit2  :Confused:   ET ben voilà onzième boot et le problème recommence... Juste pour le fun je vais créer un .cache dans mon home appartenant à root, histoire de voir si cela provoque des erreurs dans mes logs au démarrage de la session(car absolument rien d'afférent à xdg actuellement !)

----------

## gglaboussole

Problème bel et bien résolu je pense ( non reproduit en tous cas ), j'avais en fait omis l' "export" dans l'assignation de ma variable d'environnement.

En clair j'avais écrit :

```

 XDG_CACHE_HOME=/tmp/$USER/.cache

```

au lieu de 

```

export  XDG_CACHE_HOME=/tmp/$USER/.cache

```

 :Embarassed: 

----------

## kwenspc

C'est vraiment un problème l'utilisation du ssd? À part que des bénéfices (en termes de perfs/bruit) j'ai jamais noté quoique ce soit de moins bien que les hdd.

À part le trim qui n'était pas supporté par certains fs au tout début (ou du moins pas de manière transparente)... mais depuis c'est réglé ça.

D'autant qu'avec /tmp, /var/tmp en tmpfs, donc en ram, ça risque pas d'aller sur le ssd. À moins bien sûr d'être limité en ram.

----------

## gglaboussole

Salut kwenspc,

Par défaut le cache XDG n'est pas en tmpfs mais dans ton Home !

Mon but était juste de limiter les écritures sur le ssd en suivant ce tuto : http://wiki.gentoo.org/wiki/SSD#XDG_cache

Après j'ai lu ici et là que ça ne concernait que les vieux ssd, mais dans le doute, vu que ça fait déjà qq années que je vois sur des sites le ssd que j'ai acheté (corsair neutron) je ne sais pas s'il peut être considéré comme un vieux ssd ou un récent...

La solution qui est proposée dans ce tuto marchait très bien mais elle ne me semblait pas propre (lis un peu plus haut dans mon post   :Wink:  ) car si on a plusieurs sessions ouvertes elles vont se retrouver à partager le même cache !

Je voulais donc mettre ce cache dans /tmp qui est en effet en tmpfs par défaut avec systemd (et donc épargner des écritures sur mon ssd) .

Je ne voulais pas passer par /etc/env.d/ comme proposé dans le tuto...mais trouver un moyen d'encapsuler chaque .cache de chaque utilisateur dans un répertoire qui leur est  propre... de la forme /tmp/$USER/.cache

----------

## kwenspc

Ah c'est pas mal en fait, ça a un certains avantage pour la vie privée aussi, en partie.

----------

## jotake

Bonjour, 

Je m'incruste tout doucement...

Je viens de commander un SSD (Samsung PRO 850 http://www.ldlc.com/fiche/PB00170018.html pour y deplacer mon systeme dessus.

Question: Est-il toujours deconseillé de laisser /tmp et surtout /var/tmp/portage sur le SSD sous peine de l'user prématurément ?

Car je dispose seulement de 6giga de ram pour deplacer en tmpfs.

J'utilise ext4 comme FS.

----------

## ghoti

 *jotake wrote:*   

> Question: Est-il toujours deconseillé de laisser /tmp et surtout /var/tmp/portage sur le SSD sous peine de l'user prématurément ?
> 
> Car je dispose seulement de 6giga de ram pour deplacer en tmpfs.

 

Les SSD actuels sont conçus pour supporter au moins 70 Go d'écriture par jour pendant 5 ans.

Un utilisateur normal dépasse rarement 10 à 20 Go par jour. A ce rythme, ton SSD sera complètement obsolète avant même de commencer à donner le moindre signe de faiblesse !  :Wink: 

Lors des montages, ne tout même pas oublier l'option noatime !  :Wink: 

Cela dit, rien ne t'empêche de faire des compromis : garder ton tmpfs pour compiler les paquets ordinaires et définir un PORTAGE_TMPDIR spécial sur ton SSD pour les paquets les plus gourmands (genre libreoffice).

Voir https://wiki.gentoo.org/wiki//etc/portage/env

----------

## jotake

Hum, merci pour l'info et le tuto.

Je viens de tester ce week end rapidement de compiler quelques paquets en tmpfs, genre firefox.

Ca peut-être assez intéressant faut avouer...

     Wed May  6 23:19:48 2015 >>> www-client/firefox-37.0.2

       merge time: 45 minutes and 7 seconds.

     Sat May 16 19:17:47 2015 >>> www-client/firefox-37.0.2

       merge time: 29 minutes and 49 seconds.

Pour le test, j'avais créer un tmpfs de 4 giga sur mes 6 gigas.. Par moment, le système avez de petit "lag"... normal je suppose.

A approfondir...

Edit

ps: je sais je suis un méchant est suis passé chez Funtoo.

Il y a peut-être quelques particularités

----------

## gglaboussole

Salut,

Attention, pour la validité de tes tests comparatifs, pense à désactiver ccache si tu l'utilises... dans le cas contraire il serait logique que tu aies une deuxième compilation plus rapide que la première !

----------

## Leander256

Je vais laisser ça traîner ici: https://blog.flameeyes.eu/2010/07/debunking-ccache-myths-redux#gsc.tab=0

Résumé "trop long, pas lu" et/ou "j'ai du mal avec l'anglais": ccache n'apporte rien à l'utilisateur moyen de Gentoo.

----------

## jotake

J'ai eu testé ccache il y a longtemps, genre au moins 6 ans et je n'ai jamais vraiment été convaincu.

Donc, il n'est pas activé sur ma machine. Je pars du principe que si la compile est trop longue, alors elle a lieu la nuit...  :Smile: 

----------

## jotake

Bonjour, 

Je vais à nouveau squatter le fil... merci de me dire s'il faut ouvrir un nouveau sujet.

Hdparm est-il fiable pour tester un disque ssd ?

Avec mon samsung 850 pro, j'obtiens ceci: 

```
 /dev/sda:

 Timing cached reads:   14034 MB in  2.00 seconds = 7020.69 MB/sec

 Timing buffered disk reads: 806 MB in  3.01 seconds = 268.10 MB/sec

```

Mes partitions sont montées avec les options "discard et noatime"

Cf:  https://wiki.archlinux.org/index.php/SSD_Benchmarking#Using_hdparm  je suis un peu en dessous...

----------

## gglaboussole

Alors si tu as un controller SATA 2 tes valeurs sont tout à fait normales si ton controller est SATA 3 il faut creuser...

Sinon pour répondre à ta question sur le fait d'ouvrir un nouveau sujet, normalement oui car 1 question précise = 1 sujet , et je dis pas ça parce que c'est "mon" sujet   :Very Happy:   mais

parce que ça augmente tes chances d'obtenir une réponse et facilite les recherches des autres utilisateurs...

----------

