Journal Un fstab bien configuré pour un ordinateur « de bureau »

Posté par OKComputer le 08 septembre 2012 à 14:46. Licence CC By‑SA.

Étiquettes :

sept.

2012

Sommaire

Les trucs utiles
Exemple personnel
- Ma configuration
- Fichier fstab
Et maintenant ?

Bonjour journal de Linuxfr,

Ça fait quelque temps que je te lis mais c'est la première fois que je t'écris.
Je suis un auto-didacte avec Linux depuis quelques années mais pas un expert, aussi sois indulgent avec mon niveau technique, modeste.

Pour un premier journal, je voudrais me pencher sur le fichier fstab (et ce qui en est lié : partitionnement, systèmes de fichier, etc). Ce fichier joue sur le disque dur qui est l'élément le plus lent de l'ordinateur, alors une configuration expliquée et rationnelle pourrait apporter, ne serait-ce qu'un peu, plus de performance et de sécurité à cet organe électronique (et une meilleure compréhension du système pour moi).

D'abord je vais lister les trucs et astuces utiles que j'ai glané sur le Web, après je te posterai mon fichier fstab et quelques détails sur ma configuration matérielle pour que tu puisses m'aider, si tu le veux, à affiner le paramétrage de ce fichier.

Les trucs utiles

Aligner les partitions sur des cylindres du disque dur

C'est une astuce, dont j'ai perdu la source, mais qui améliore(rait) un peu les performance du disque dur. Je partitionne mon disque dur en utilisant GParted (car il peut créer une partition en les alignant sur un cylindre a contrario de la plupart des installateurs de nos distributions) sur un système Live avant l'installation (où je n'ai qu'à réutiliser les partitions pré-découpées).

Créer des partitions distinctes

Pour des raisons de sécurité et de sûreté des données, il est préférable de créer des partitions pour /boot, /var, /tmp et /home (voire /opt pour ceux qui compilent des trucs pour leur système) distinctes de la partition racine /.

Utiliser un système de fichier optimisé pour les différents usages

Le système de fichier a une incidence sur les performances du disque dur.
J'ai trouvé que ReiserFS est préférable pour la partition /var (très performant pour l'écriture des petits fichiers).
XFS est préférable pour la partition /home, mais on est loin des avantages qu'offre ext4, donc ce dernier resterait préférable.
Tmpfs est une bonne option pour les dossiers temporaires (/tmp, /var/tmp).

Y'a-t-il d'autres systèmes de fichier à conseiller pour un usage précis dans le cadre de mon usage ?

L'option "noatime"

Cette option désactive la mise à jour des dates d'accès et de modification de tous les fichiers sur la partition concernée par l'option. C'est une option utile pour un serveur mais pas pour nos ordinateurs « de bureau », donc on peut l'ajouter à toutes les partitions dans le cas présent.

http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec73.html

Les options "discard" et "data=ordered" (pour SSD uniquement)

Ces options nécessitent un formatage de la partition en ext4 mais permettent l'activation de ce qu'on appelle communément le TRIM. Ce qui est nécessaire pour contenir l'usure prématurée du SSD.

https://wiki.archlinux.org/index.php/Solid_State_Drives#Mount_Flags
http://www.debian-fr.org/ssd-trim-discard-n-est-pas-pris-en-compte-t37357.html

Mettre /tmp et /var/tmp en RAM

Pour ce faire, il faut rajouter les deux dernières lignes de mon fstab ci-après.
La taille allouée à chaque dossier est modifiable par l'option size=*m.

Ça a pour avantage :
1. d'accélérer le système car la RAM étant plus rapide que le disque dur.
2. de réduire l'usure du disque dur (qui n'est plus sollicité car étant remplacé par la RAM).

Les options "nosuid", "noexec" et "nodev"

Ces options permettent une réduction - du moins une limitation - des privilèges avec les options de mount. Je passe sur ce que font ces options, il y a le man pour ça.

Ajouter l'option noexec pour toutes les partitions sur le disque dur sauf la partition racine (/), la partition /var° et la partition /home°°.
Ajouter l'option nodev pour toutes les partitions sauf la partition racine (/) et d'éventuelles partitions chroot.
Ajouter l'option nosuid pour toutes les partitions sauf la partition racine (/).

Je te confesse n'avoir que recopié les conseils donnés dans la source ci-dessous (page 15)
http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf

° : surtout avec Debian et dérivés, Aptitude en souffrirait beaucoup.
°° : Car cela empêche l'exécution de tout script dans le dossier de l'utilisateur, je trouve cette option pratique pour les ordinateurs des personnes lambda (feu Mme Michu). Prenons l'exemple de cette personne qui utilise son ordinateur pour consulter des méls et télécharger tout et n'importe quoi comme par exemple clique-ici-pour-savoir-qui-consulte-ton-profil-Facebook.sh … Un petit truc silencieux au but obscur qui s'installe en douce dans un dossier caché, à l'insu de l'utilisateur, sans qu'un bon mot de passe ou un système bien à jour puisse y faire quelque chose.

Exemple personnel

Ma configuration

J'utilise un ordinateur « de bureau » comportant un SSD (de récupération) installé en parallèle d'un disque dur. La faible taille du SSD fait que je ne peux me permettre d'y installer l'intégralité du système. Aussi, ai-je décidé de n'installer que les partitions / et /boot sur ce périphérique, plaçant les autres sur le disque dur. J'ai également séparé la partition /var (qui, comme tu le sais, contient entre autre les journaux d'activité) de la partition racine et l'ai placée sur le disque dur (dans le souci de prévenir toute usure prématurée des cellules mémoire de mon disque électronique par des écritures trop fréquentes).

Fichier fstab

UUID=XXX       /               ext4        defaults,noatime,discard,data=ordered                                   1 1
UUID=XXX       /boot           ext4        defaults,noatime,nosuid,noexec,nodev,discard,data=ordered               1 2
UUID=XXX       /home           ext4        defaults,noatime,nosuid,noexec,nodev                                    1 2
UUID=XXX       /var            ReiserFS    defaults,noatime,nosuid,nodev                                           1 2
UUID=XXX       swap            swap        defaults                                                                0 0

tmpfs          /dev/shm        tmpfs       defaults,noatime,nosuid,noexec,nodev                                    0 0
tmpfs          /tmp            tmpfs       defaults,noatime,nosuid,noexec,nodev,mode=1777,size=768m                0 0
tmpfs          /var/tmp        tmpfs       defaults,noatime,nosuid,noexec,nodev,mode=1777,size=256m                0 0

Et maintenant ?

Dis-moi, que penses-tu des informations données ci dessus ? Qu'y a-t-il à corriger ? Que pourrais-je rajouter ?
À propos de la ligne /dev/shm, est-elle vraiment utile ? Je ne sais quoi en penser.

Merci de ton aide !

PS : Je n'ai pas tout compris à cette histoire karma et c'est la première fois que j'écris, j'espère que tu jugeras ce journal avec indulgence.

# Attention !

Posté par Xaapyks le 08 septembre 2012 à 15:00. Évalué à 10.

Qu'y a-t-il à corriger ?

Ceci, ce n'est pas une bonne idée du tout :

Mettre /tmp et /var/tmp en RAM

/var/tmp doit être préservé entre chaque reboot.
Source : Le FHS http://proton.pathname.com/fhs/pub/fhs-2.3.html

De plus "data=ordered" n'est pas réservé aux SSD, c'est pour modifer le comportement du journal, il peut être activé sur n'importe quel ext4, même ext3 il me semble (à vérifier). Selon les noyaux, il est par défaut en ordered.
- [^] # Re: Attention !
  
  Posté par OKComputer le 08 septembre 2012 à 19:04. Évalué à 1.
  
  /var/tmp doit être préservé entre chaque reboot.
  Source : Le FHS http://proton.pathname.com/fhs/pub/fhs-2.3.html
  
  OK, merci pour la correction !
  
  De plus "data=ordered" n'est pas réservé aux SSD, c'est pour modifer le comportement du journal, il peut être activé sur n'importe quel ext4, même ext3 il me semble (à vérifier). Selon les noyaux, il est par défaut en ordered.
  
  Oui, j'ai mal formulé. Mais dans certains cas (où ordered n'est pas par défaut, cf. le lien vers le forum Debian-fr) cette option peut être nécessaire pour activer le TRIM. Dans le doute, je l'ai ajoutée ici.
- [^] # Re: Attention !
  
  Posté par zebra3 le 10 septembre 2012 à 13:17. Évalué à 3.
  
  Bof, ça fait des années que mon /var/tmp est en RAM et je n'ai jamais eu aucun souci.
  
  Y'a encore des programmes qui écrivent là-dedans ?
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Attention !
    
    Posté par Anonyme le 10 septembre 2012 à 14:16. Évalué à 3.
    
    KDE notamment.
# noatime, noexec

Posté par Patrick Lamaizière (site web personnel) le 08 septembre 2012 à 15:15. Évalué à 8.

L'option "noatime". Cette option désactive la mise à jour des dates d'accès et de modification

Désctive juste la mise à jour de la date d'accès (qui est assez peu utile). La date de modification est actualisée.

Ajouter l'option noexec pour toutes les partitions sur le disque dur sauf la partition racine (/), la partition /var° et la partition /home°°.

noexec c'est surtout du vent. Ça n'empêche aucunement l'exécution, soit en appelant l'intépreteur directement (pour un script), soit en appelant le loader.

les pixels au peuple !
- [^] # Re: noatime, noexec
  
  Posté par Sufflope (site web personnel) le 08 septembre 2012 à 15:27. Évalué à 10.
  
  noexec c'est surtout du vent. Ça n'empêche aucunement l'exécution, soit en appelant l'intépreteur directement (pour un script), soit en appelant le loader.
  
  Ça fait depuis Linux 2.4 que l'astuce d'appeler ld.so ne marche plus pour lancer un exécutable sur une partition noexec… faudrait passer au XXIème siècle un de ces jours.
  - [^] # Re: noatime, noexec
    
    Posté par Misc (site web personnel) le 09 septembre 2012 à 11:46. Évalué à 2.
    
    ça marchait encore en 2.4 ( vu que je m'en suis servi il y a longtemps ), mais je confirme que ça a disparu y a une paire d'années déjà ( quand exactement, je sais pas )
- [^] # Re: noatime, noexec
  
  Posté par Marotte ⛧ le 08 septembre 2012 à 18:17. Évalué à 2.
  
  Je vais peut-être (encore) passer pour une buse mais dans le cas d'un /usr séparé je pense qu'il ne faut pas non plus mettre noexec sur cette partition.
  - [^] # Re: noatime, noexec
    
    Posté par R. Danell Olivaw le 08 septembre 2012 à 18:59. Évalué à 1.
    
    Certes, mais il me semble, que le /usr séparé est «déconseillé» lorsque l'on compte utiliser systemd comme système d'init.
    - [^] # Re: noatime, noexec
      
      Posté par Mjules (site web personnel) le 08 septembre 2012 à 21:11. Évalué à 3.
      
      C'est déconseillé avec tout si tu ne fais pas le montage dans l'initrd, la différence, c'est que systemd écrit un message dans les logs à ce sujet.
      http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
      - [^] # Re: noatime, noexec
        
        Posté par Olivier Serve (site web personnel) le 09 septembre 2012 à 10:04. Évalué à 2.
        
        Et surtout que udev >= 181 ne marche plus
    - [^] # Re: noatime, noexec
      
      Posté par Joris Dedieu (site web personnel) le 10 septembre 2012 à 16:57. Évalué à 4.
      
      Certes, mais il me semble, que le /usr séparé est «déconseillé» lorsque l'on compte utiliser systemd comme système d'init.
      
      A oui, c'est vrai qu'il met sa config dans /usr/lib/systemd …
      
      OK =========> Je sors
- [^] # Re: noatime, noexec
  
  Posté par calandoa le 10 septembre 2012 à 14:46. Évalué à 5.
  
  « [noatime ] désctive juste la mise à jour de la date d'accès (qui est assez peu utile) »
  
  Au contraire, on peut facilement faire des trucs sympa. Par exemple, pour afficher le dernier fichier lu d'un répertoire avec zsh : print -l *(.oa[-1])
  
  J'utilisais ça pour faire tourner les fonds d'écrans à une époque.
  
  Ou encore, pour savoir quels fichiers ont été utilisé lors de la compilation d'un gros projet :
  touch toto
  make whatever
  find -anewer toto
  
  À noter que certaines distribs restreignent cette fonctionnalité au niveau du noyau Linux avec l'option DEFAULT_RELATIME (ou encore au boot avec norelatime). Ce champ n'est alors mis à jour que si le délai est suffisamment grand (1 jour par défaut). On peut modifier le délai à 10s avec un :
  print 10 > /proc/sys/fs/relatime_interval
# attention au tmpfs

Posté par Zylabon le 08 septembre 2012 à 15:29. Évalué à 5.

J'ai eu un système qui ne boutait plus une fois à cause d'un /tmp en tmpfs saturé, le gain de performances étant finalement relativement faible, j'y ai renoncé.

Sinon :

btrfs est vraiment extra, avec la compression on divise par deux l'occupation des partitions qui contiennent des données compressibles, et augmente d'autant les performances en entrée sortie. Il est possible d'avoir autant de partition que l'on veut sans se soucier de leur taille, défragmenter à chaud, faire des snapshots dans lesquels on peut écrire, bref, c'est génial.

Pour la sécurité on peut monter en lecture seule tout ce qui peut l'être, et peut être que le /boot n'a pas besoin d'être monté automatiquement.

Personne n'a compris l’intérêt de cette histoire de karma, c'est une solution compliquée et grossière à un problème inexistant.

Please do not feed the trolls
- [^] # Re: attention au tmpfs
  
  Posté par Sylvain Blandel le 08 septembre 2012 à 16:49. Évalué à 7.
  
  un système qui ne boutait plus une fois à cause d'un /tmp en tmpfs saturé
  
  Je ne comprends pas.
  
  Si on met le /tmp en tmpfs, /tmp est vidé à chaque arrêt de la machine. Donc, lorsque l'on redémarre, /tmp ne peut pas être saturé : il ne contient rien au démarrage. Ce n'est pas cela qui bloquait le boot, non ?
  - [^] # Re: attention au tmpfs
    
    Posté par Zylabon le 08 septembre 2012 à 17:04. Évalué à 0.
    
    J'ai fais des tests, effectivement, ça ne semble pas poser de problème, même en le saturant.
    
    Sinon c'était pas au démarrage qu'il y avait eu le problème, mais à l'arrêt, le système était resté dans un état incohérent, je ne me souviens plus comment par contre.
    
    Please do not feed the trolls
# J'ai désactivé tmpfs

Posté par ®om (site web personnel) le 08 septembre 2012 à 15:52. Évalué à -6.
Le tmpfs est activé par défaut sur Debian testing pour /tmp et /run/shm (séparément de /run). Mais je l'ai désactivé, car ça diminue la taille de ram disponible pour le reste, y compris si /tmp ou /run/shm sont quasiment vide.

Un cas concret : au boulot, j'ai un pc avec 4G de ram.
/tmp occupait 800M
/run occupait 400M
/run/shm occupait 800M

Ce qui fait 2G d'utilisé, sans avoir rien lancé.

Avec Firefox (iceweasel) + 2 Eclipse + 1 emulateur Android, la machine est à genoux.

50% de la RAM de perdue. Pour quel bénéfice ? Aucun.

Pour désactiver le tmpfs sur /tmp et /run/shm, il faut modifier /etc/default/tmpfs (avant c'était dans /etc/default/rcS) :
```
RAMSHM=no #le commentaire dit que c'est à "no" par défaut, mais il me semble que ça n'est pas vrai, à retester
RAMTMP=no
```
blog.rom1v.com
- [^] # Re: J'ai désactivé tmpfs
  
  Posté par Mjules (site web personnel) le 08 septembre 2012 à 16:20. Évalué à 10.
  tmpfs ne prend pas de RAM si il n'est pas utilisé.
  
  tmpfs puts everything into the kernel internal caches and grows and
  shrinks to accommodate the files it contains and is able to swap
  unneeded pages out to swap space.
  
  https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
```
[jules@tue-amour ~]$ df |grep tmpfs
devtmpfs         1,9G     0  1,9G   0% /dev
tmpfs            2,0G   68K  2,0G   1% /dev/shm
tmpfs            2,0G  712K  2,0G   1% /run
tmpfs            2,0G     0  2,0G   0% /sys/fs/cgroup
[jules@tue-amour ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:          3956       1325       2631          0         83        634
-/+ buffers/cache:        607       3348
Swap:         4844          0       4844
```
  - [^] # Re: J'ai désactivé tmpfs
    
    Posté par ®om (site web personnel) le 08 septembre 2012 à 16:37. Évalué à 2. Dernière modification le 08 septembre 2012 à 16:38.
    
    Merci de la précision, je ne savais pas.
    
    Mon /tmp était pas mal rempli (je wget souvent des trucs dans /tmp), ce qui devait expliquer le problème.
    Depuis que j'ai désactivé tmpfs pour /tmp, ça fonctionne beaucoup mieux.
    
    Question au passage : quel intérêt de monter /run/shm dans un tmpfs séparé de /run ?
    
    blog.rom1v.com
- [^] # Re: J'ai désactivé tmpfs
  
  Posté par SChauveau le 08 septembre 2012 à 16:27. Évalué à 2.
  
  tmpfs n'utilise que la mémoire nécessaire pour stocker les fichiers donc un tmpfs vide n'utilise rien (ou presque). Dans le cadre d'une utilisation normale, /tmp et /run/shm ne sont pas censés contenir une grande quantité de données.
  
  Qu'est ce que qui peut donc mettre la machine a genoux avec Firefox (iceweasel) + 2 Eclipse + 1 émulateur Android? La réponse est probablement dans la question.
  - [^] # Re: J'ai désactivé tmpfs
    
    Posté par Zylabon le 08 septembre 2012 à 16:43. Évalué à 3.
    
    Je connais au moins deux programmes courants qui peuvent mettre plusieurs centaines de mégas rapidement dans /tmp : imagemagik et firefox.
    
    Please do not feed the trolls
  - [^] # Re: J'ai désactivé tmpfs
    
    Posté par Spack le 08 septembre 2012 à 16:52. Évalué à 5.
    
    Et il est bien là le problème. Certain programmes peuvent y mettre de très gros fichiers. Le sujet à longuement été débatu sur la liste de diffusion de Debian. Ce post résume un peu les différents problèmes que l'on peut rencontrer.
- [^] # Re: J'ai désactivé tmpfs
  
  Posté par rewind (Mastodon) le 08 septembre 2012 à 21:08. Évalué à 2.
  
  Il y a des discussions à ce sujet :
  https://lwn.net/Articles/499410/
# Montage automatique des partitions avec systemd

Posté par Sylvain Blandel le 08 septembre 2012 à 17:26. Évalué à 9.
Les utilisateurs de systemd bénéficient de l'option x-systemd.automount pour un montage automatique des partitions.

Un extrait de mon fichier /etc/fstab :
```
/dev/sda7  /media/zaza  ext4  x-systemd.automount,…  0  2
```
Situation initiale : cette partition n'est pas montée :
```
$ mount | grep sda7
(Aucun retour)
```
Un programme souhaite accéder à cette partition (par exemple, le programme ls) :
```
$ ls /media/zaza
fichier1  fichier2  fichier3  …
```
Le contenu de la partition apparait ! La partition est maintenant montée !
```
$ mount | grep sda7
/dev/sda7 on /media/zaza type ext4 …
```
Que s'est-il passé ? Lorsqu'un programme a souhaité accéder au contenu de la partition, systemd a monté la partition automatiquement, sans intervention de l'utilisateur.

Plus d'info sur cette fonctionnalité sur le site de systemd : systemd.mount et systemd.automount.
- [^] # Re: Montage automatique des partitions avec systemd
  
  Posté par Olivier Serve (site web personnel) le 10 septembre 2012 à 00:23. Évalué à -1.
  
  Et euh, ça sert à quoi ?
  - [^] # Re: Montage automatique des partitions avec systemd
    
    Posté par Sylvain Blandel le 10 septembre 2012 à 10:04. Évalué à 1.
    ça sert à quoi ?
    
    Sans l'option « x-systemd.automount » :
```
$ cd /media/sda8/sauvegardes
-bash: cd: /media/sda8/sauvegardes: Aucun fichier ou dossier de ce type
```
    « Ah zut ! La partition sda8 n'est pas monté, il faut que la monte manuellement. »
    
    Avec l'option « x-systemd.automount » :
```
$ cd /media/sda8/sauvegardes
(La partition sda8 n'est pas montée)
(Systemd monte la partition automatiquement)

$ pwd
/media/sda8/sauvegardes
```
    Bien entendu, il est toujours possible de monter manuellement ses partitions avec la commande mount. De plus, les utilisateurs de systemd sont libres de ne pas utiliser cette option.
    - [^] # Re: Montage automatique des partitions avec systemd
      
      Posté par Olivier Serve (site web personnel) le 10 septembre 2012 à 12:12. Évalué à 1.
      
      Euh, chez moi, sans l'option x-systemd-automount, la partition est montée au démarrage et basta.
      Ou bien c'est udev qui gère le montage des périphériques amovibles dans /media.
      
      Donc je ne vois pas trop l'intérêt.
      - [^] # Re: Montage automatique des partitions avec systemd
        
        Posté par Shuba le 10 septembre 2012 à 12:20. Évalué à 2.
        
        Je pense que l'intérêt est dans le cas d'un disque réseau, qui peut ne pas être disponible. Autant informer qu'il n'est pas accessible lorsqu'on tente effectivement de l'utiliser.
    - [^] # Re: Montage automatique des partitions avec systemd
      
      Posté par zebra3 le 10 septembre 2012 à 13:19. Évalué à 4.
      
      C'est ce que fait autofs, non ?
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: Montage automatique des partitions avec systemd
        
        Posté par briaeros007 le 10 septembre 2012 à 14:19. Évalué à 5.
        
        oui, depuis plus de 15 ans, avec une gestion bien plus intéressante car tu peux monter les points de montages des utilisateurs sans avoir à tous les préciser dans le fichier (il peut attaquer le nis, le ldap, …)
    - [^] # Re: Montage automatique des partitions avec systemd
      
      Posté par briaeros007 le 10 septembre 2012 à 14:19. Évalué à 3.
      
      on est pas aveugle ni sourd, merci.
      
      Et la poudre à réinventer le canon, ça fait plaisir aux newbies, mais comme dis un autre commentaire, autofs sait le faire depuis plus de 15 ans, et on met pas des heading 1 pour indiquer que systemd viens de complexifier encore un truc qui marchait bien sans (tu les fous où tes noms d'utilisateurs ? )
      
      Sans compter que, sauf erreur de ma part, ca nous viens initialement de solaris et de yellow page.
      
      "Moi je prend sans rien donner en échange" serait une bonne définition de systemd finalement
# Mes deux centimes

Posté par Marotte ⛧ le 08 septembre 2012 à 18:52. Évalué à 6. Dernière modification le 08 septembre 2012 à 18:57.
PS : Je n'ai pas tout compris à cette histoire karma et c'est la première fois que j'écris, j'espère que tu jugeras ce journal avec indulgence.

J'ai jugé ton journal pertinent. Ça perle d'informatique, de GNU/Linux, c'est assez bien écrit je trouve (les fautes s'il y en a ne m'ont pas sauté aux yeux).

Le karma c'est expliqué ici.

Pour répondre sur le fond :
- /var/tmp en tmpfs c'est pas bien comme ça a déjà été dit (/var/tmp doit persister au reboot). /tmp en tmpfs faut faire attention mais ça peut valoir le coup.
- Tu peux aussi mettre /var/lock en tmpfs avec l'option RAMLOCK=yes dans /etc/default/rcS (pour Debian et Ubuntu au moins)
- Ne pas oublier de mettre comme espace réservé pour le super-utilisateur seulement 1% (au lieu de 5% par défaut) pour les grosses partitions.
.

Je n'ai jamais compris à quoi servait /opt, pour moi un programme compilé localement, qui ne fait pas partie de la distribution (en tous cas la même version) ça va dans /usr/local, que l'on peut déjà très bien coller sur une partition dédiée. /opt c'est pour les programmes tiers distribués sous forme de binaire ?

Ce qui m'a toujours soulé lors d'un partitionnement c'est d'évaluer la volumétrie nécessaire à chaque partition, surtout sur un desktop personnel pour lequel on a pas toujours forcément une idée très précise de l'usage futur. Puis j'ai découvert LVM et ma vie a changé.

Maintenant je crée un volume physique LVM qui fait tout le disque dur puis un lecteur logique pour chaque partition qui ont un volume minimum, juste quelques Go pour /usr par exemple. Ensuite, quand j'ai besoin d'espace, un coup de lvresize pour augmenter la taille de mon volume logique, puis un coup de resize2fs (qui sans argument va utiliser tout l'espace que je viens d'ajouter) et c'est règlé. Ça c'est pour du ext4, mais je suppose que d'autre filesystems peuvent également augmenter leur taille à chaud.
- [^] # Re: Mes deux centimes
  
  Posté par gouttegd le 08 septembre 2012 à 22:14. Évalué à 4.
  
  Je n'ai jamais compris à quoi servait /opt, pour moi un programme compilé localement, qui ne fait pas partie de la distribution (en tous cas la même version) ça va dans /usr/local, que l'on peut déjà très bien coller sur une partition dédiée. /opt c'est pour les programmes tiers distribués sous forme de binaire ?
  
  Personnellement, j’y mets surtout des programmes qui s’intègrent assez mal (ou pas du tout) dans une arborescence Unix « classique » (j’entends par là, les exécutables dans bin, les bibliothèques dans lib, les fichiers de données dans share, etc.) — typiquement, des programmes Java.
  - [^] # Re: Mes deux centimes
    
    Posté par leovilok le 08 septembre 2012 à 22:40. Évalué à 3.
    
    Après il y a aussi la vision de Slackware, pour eux opt est pour les "software packages" : pas les paquets logiciels mais les paquets de logiciels, les groupes/compilations cohérents de logiciels qu'on veut pouvoir enlever d'un coup plus facilement que si c'était dispersé dans /usr/*. Par exemple ils y mettent KDE.
    En tout cas c'est ce qui est dit dans le manuel.
    - [^] # Re: Mes deux centimes
      
      Posté par gouttegd le 08 septembre 2012 à 23:09. Évalué à 2.
      
      Par exemple ils y mettent KDE. En tout cas c'est ce qui est dit dans le manuel.
      
      Le manuel n’est pas à jour alors, parce que KDE est désormais dans /usr, depuis Slackware-12.0 si je me souviens bien. En fait, dans les dernières Slackware aucun paquet officiel n’installe quoi que ce soit dans /opt.
  - [^] # Re: Mes deux centimes
    
    Posté par Eldermê (site web personnel) le 11 septembre 2012 à 12:20. Évalué à 1.
    
    Un peu pareil pour moi : je mets dans /opt des programmes java et des programmes distribués sous forme binaire. Concrètement, j'y mets des jeux propriétaires.
    
    Mon /opt est sur une partition séparée. L'intérêt, c'est parce que j'ai plusieurs distributions, chacune va donc utiliser le même /opt. Cela me permet de jouer depuis n'importe quelle distribution sans avoir à dupliquer des données qui seraient exactement les mêmes.
- [^] # Re: Mes deux centimes
  
  Posté par claudex le 09 septembre 2012 à 11:01. Évalué à 4.
  
  Ne pas oublier de mettre comme espace réservé pour le super-utilisateur seulement 1% (au lieu de 5% par défaut) pour les grosses partitions.
  
  Qu'est-ce qu'une grosse partition ? 50 Go, 500 Go, 5To ?
  
  Je n'ai jamais compris à quoi servait /opt, pour moi un programme compilé localement, qui ne fait pas partie de la distribution (en tous cas la même version) ça va dans /usr/local, que l'on peut déjà très bien coller sur une partition dédiée. /opt c'est pour les programmes tiers distribués sous forme de binaire ?
  
  Surtout les programmes qui ne respecte par la hiérarchie classique, pas de le programme propriétaires se mettent dans /opt.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Mes deux centimes
    
    Posté par Marotte ⛧ le 09 septembre 2012 à 12:27. Évalué à 3. Dernière modification le 09 septembre 2012 à 12:28.
    
    50 Go c'est déjà gros. Si je ne me trompe pas 5% de 50 Gio ça fait 2560 Mio, je ne pense pas qu'il soit nécessaire de réserver autant pour le super-utilisateur, 1% soit 512 Mio suffit.
    
    Merci à vous pour la réponse sur /opt, c'est plus clair pour moi maintenant.
    - [^] # Re: Mes deux centimes
      
      Posté par groumly le 09 septembre 2012 à 23:00. Évalué à 3.
      
      Pourquoi parler en pourcentage?
      Une taille en Mo/Go parait plus adaptee…
      
      Derniere chose, c'est quoi cette manie de partitioner a tout va?
      A part se retrouver bloquer avec une partition trop petite (ou une trop grande), je vois pas franchement ce que ca va apporter et s'emmerder avec des montages de partout, ca va 5 minutes.
      
      Pour ce qui est de restaurer un systeme, les backups c'est pas fait pour les chiens.
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Mes deux centimes
        
        Posté par Marotte ⛧ le 09 septembre 2012 à 23:06. Évalué à 2.
        
        Pourquoi parler en pourcentage?
        
        Parce que l'installeur parle en pourcentage ?
        
        se retrouver bloquer avec une partition trop petite (ou une trop grande)
        
        D'où tout l'intérêt de LVM.
        
        [^] # Re: Mes deux centimes
        
        Posté par groumly le 10 septembre 2012 à 00:07. Évalué à 5.
        
        Decoupons le disque en plein de petits bouts, et comme c'est pas pratique et que ca apporte rien, utilisons ensuite un programme qui permet de faire apparaitre ces petits bouts comme un gros bout.
        Je suis le seul a avoir du mal avec le concept?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mes deux centimes
        
        Posté par Marotte ⛧ le 10 septembre 2012 à 03:01. Évalué à 2.
        
        Je suis le seul a avoir du mal avec le concept?
        
        On dirait ouai.
      - [^] # Re: Mes deux centimes
        
        Posté par Marotte ⛧ le 11 septembre 2012 à 12:48. Évalué à 3.
        
        Derniere chose, c'est quoi cette manie de partitioner a tout va?
        
        Ça permet je pense de réduire la fragmentation de la partition /usr (dont les fichiers bougent peu) alors que si on colle tout (notamment /var) sur la même partition ça va fragmenter plus vite.
        
        C'est peut-être une idée fausse.
        
        Un autre raison est que l'on peut faire un snapshot LVM (ou une bête image de partition si on utilise pas LVM) seulement de /var, qui contient par exemple nos bases de données, sans avoir à y inclure /usr dont on peut facilement retrouver le contenu (en réinstallant).
# UUID, moins pratique y'a pas

Posté par Kerro le 08 septembre 2012 à 21:35. Évalué à 8.

Je n'arrive pas à me faire aux UUID des partitions.
Je trouve ça totalement illisible.
Alors certes, si on ne touche jamais a ses disques c'est parfait. Mais dès qu'on est sur serveur et qu'on veut s'assurer d'avoir des configurations lisibles, ben les UUID vont à l'encontre de cet objectif. Cela ne sert pas souvent, mais lorsqu'on a besoin d'identifier les partitions c'est généralement qu'il y a un problème. Ce n'est pas le moment de se tromper, ni de perdre du temps. Une identification claire est importante.

J'aimerais remplacer les UUID par les labels, manque de bol les développeurs de GRUB n'en veulent pas. Il y a possibilité de modifier le script de création du fichier de configuration, mais ce sera écrasé lors de la prochaine mise à jour, et c'est par définition "sale".

L'inconvénient des labels est qu'il est possible d'avoir des noms identiques lorsqu'on mélange les disques de plusieurs machines. Mais rien n'empêche l'admin d'être un poil compétent.
- [^] # Re: UUID, moins pratique y'a pas
  
  Posté par Mimoza le 10 septembre 2012 à 10:16. Évalué à 2.
  
  +1
  Ça va à l'encontre du principe KISS.
  Donc mis à part la partition boot (pour le problème de Grub que tu évoque), toutes les autres sont labellisé.
  Après l'argument "mais comme ça tu n'auras jamais de problème de point de montage" est pas vraiment significatif pour moi. Il y a 1000 autre raison d'avoir des pbs de montage.
  - [^] # Re: UUID, moins pratique y'a pas
    
    Posté par Kerro le 10 septembre 2012 à 10:25. Évalué à 2.
    
    N'avoir de l'UUID que pour la partition de boot, je n'y avait même pas pensé /o\
    
    Ce qui m'agace c'est que le "problème" vient juste d'un script. Même l'équipe Debian ne semble pas vouloir le modifier.
# Mes commentaires...

Posté par Christophe Merlet (site web personnel) le 08 septembre 2012 à 21:42. Évalué à 10.

Aligner les partitions sur des cylindres du disque dur

Les disques durs n'ont plus de cylindres depuis quelques décennies maintenant.
Aujourd'hui, il faut aligner les partitions au Mo près.

Historiquement, les disques durs fonctionne avec des clusters de 512 octets. Le système de partitionnement DOS réservait les 63 premiers clusters pour le MBR et la table de partitions. Avec l'accroissement de capacité des disques durs (> 2 To), la taille de cluster devient 4096 octets et les SSD fonctionne optimalement avec des blocs de 512 Ko voire 1Mo. De plus, les boot loader tel que grub ont de plus en plus de mal à tenir dans les 63 premiers cluster de 512 octets d'où l'apparition du schema de partitionnement GPT associé à un bios UEFI et à un OS 64 bits…
Bref, pour tenir compte de toutes ses contraintes, par anticipation ou par obligation, il vaut mieux aligner ses partitions au Mo, et adopter si possible GPT.
GPT : https://fr.wikipedia.org/wiki/GUID_Partition_Table
UEFI : https://fr.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

L'alignement doit aussi prendre en compte un éventuel RAID matériel ou logiciel, eux même devant être correctement aligné (mdadm metadata=1.0), puis lvm si utilisé…

Créer des partitions distinctes

Créer une partition pour /boot est inutile. Cela était nécessaire il y a quelques décennies lorsque le BIOS ne savait pas rendre accessible un cylindre supérieur à 1024, que les boot loader ne savait pas outrepasser cette limite et que les disques durs étaient devenu plus grand. On créait donc une partition /boot situé au dessous du cylindre 1024 et on pouvait plaçer la partition / plus loin sur le disque dur.
https://en.wikipedia.org/wiki/Cylinder_1024
Aujourd'hui , sur les ordis récents (UEFI + GPT), il faut créer une partition de type ESP (en réalité FAT12, FAT16 ou FAT32) avec l'identifiant 6 qui sera monté sous linux à /boot/efi
ESP : https://en.wikipedia.org/wiki/EFI_System_partition

les partitions / /home et swap sont indispensables. /var et /tmp selon les besoins (bien réfléchir à la taille requise)

Utiliser un système de fichier optimisé pour les différents usages

Exact. De ma propre expérience ext4 est vraiment un excellent choix. Et j'en ai fait des benchs sur tous types de matos et tous types de workflow…
En fait selon mes usages, j'optimise mes partitions ext4 lors du formatage avec les options de mke2fs :
-E stride=stride-size,stripe_width=stripe-width,lazy_itable_init=0 -m (0, 1 ou 5) -T (largefile, largefile4)

L'option "noatime"

Le kernel utilise depuis quelques années relatime par défaut. noatime n'apporte quasiment aucun bénéfice. Cependant sur le support est une mémoire flash ou un vieux SSD on peut l'activer pour économiser quelques cycles d'écriture…

Les options "discard" et "data=ordered" (pour SSD uniquement)

data=ordered ne concerne pas les SSD. De plus avec ext4 l'option data=* n'influe quasiment pas sur les performances. Autant laisser la valeur par défaut, la plus sûr pour l'intégrité des données.
discard active la fonction TRIM sur les SSD mais… c'est limite obsolète ! Il vaut mieux utiliser fstrim dans un cron pour un maximum et performance sur les SSD moderne. Inclus dans les toutes dernières versions de util-linux.
http://www.vdmeulen.net/cgi-bin/man/man2html?fstrim+8
https://patrick-nagel.net/blog/archives/337

discard active aussi l'allocation dynamique d'espace disque sur certains SAN haut de gamme dans les environnements virtualisés, mais c'est un autre sujet…
https://en.wikipedia.org/wiki/Thin_provisioning

Mettre /tmp et /var/tmp en RAM

Tu te contredis avec le fait de créer une partition pour /tmp
C'est effectivement une nouvelle mode dans certaines distribs récentes de mettre /tmp dans un RAMdisk. Je ne suis pas fan :/ Sur une machine de bureau, je vais laisser faire comme le veut la distrib, sur un serveur je vais prévoir 4 à 8 Go pour /tmp (ça peut servir, si l'espace disque n'est pas critique).
Par contre, /var/tmp ne doit absolument pas être dans un ramdisk, puisqu'il est censé être persistant d'un reboot à l'autre !

Les options "nosuid", "noexec" et "nodev"

À utiliser avec la plus grande précaution et en connaissance de cause. Un mauvais choix sur un serveur qui ferait de la virtualisation et c'est la cata. Même sur un desktop, il peut y avoir des effets de bord en fonction de l'usage qui en est fait..

Puisque l'on parle de performance des disques, on peut aussi modifier le scheduler /sys/block/sd/queue/scheduler en noop (ssd ou raid matériel avec BTU), deadline (database) ou cfq (desktop)
Augmenter la valeur de /sys/block/sd/queue/read_ahead_kb
modifier /sys/block/sd/queue/nr_requests et /sys/block/sd/queue/iosched/* pour jouer avec la latence et les io/s (attention, ne pas faire n'importe quoi. linux est déjà très optimisé par défaut)
Ya plein d'autres options , lecture de doc et surtout des sources du kernel pour découvrir leur rôle exact)
- [^] # Re: Mes commentaires...
  
  Posté par neil le 09 septembre 2012 à 10:43. Évalué à 1.
  
  Créer des partitions distinctes
  
  Je pense qu’il parlait d’/usr /o\
- [^] # Re: Mes commentaires...
  
  Posté par claudex le 09 septembre 2012 à 11:06. Évalué à 6.
  
  Créer une partition pour /boot est inutile.
  
  C'est encore utile en cas de multiboot de distribution linux pour avoir un seul grub pour toutes.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Mes commentaires...
    
    Posté par François Chaix (site web personnel) le 09 septembre 2012 à 15:19. Évalué à 3.
    
    C'est aussi utile dans le cas d'un système dont la partition / est chiffrée…
    
    La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.
    - [^] # Re: Mes commentaires...
      
      Posté par Misc (site web personnel) le 09 septembre 2012 à 15:41. Évalué à 2.
      
      Grub2 supporte luks ( en théorie ), donc ça devrait passer. ( et lvm, et le raid aussi )
  - [^] # Re: Mes commentaires...
    
    Posté par Misc (site web personnel) le 09 septembre 2012 à 15:44. Évalué à 4.
    
    En pratique, je conseille souvent de faire 2 niveau de bootloaders. 1 qui est sous le contrôle de l'admin, qui chainload vers X grubs pour chaque distribution ( installer sur la partoche racine de la distribution ).
    
    Chaque distribution gére son bootloader sur sa partoche ( genre les mises à jours noyau ) et l'admin gère à la mano le grub primaire qui bascule sur les autres. Comme ça, il le change que si il y a une nouvelle distribution.
- [^] # Re: Mes commentaires...
  
  Posté par benoar le 10 septembre 2012 à 23:04. Évalué à 2.
  
  Aujourd'hui, il faut aligner les partitions au Mo près.
  
  Oui. Et ne surtout pas aligner aux cylindres qui te font souvent commencer ta première partition au secteur 63 : c'est la grosse merde (niveau perfs) avec les disques 4k (= la plupart des disques aujourd'hui, et d'autant plus les SSD). En fait, ce journal a des conseils sympas, mais des conseils d'il y a 5 ans (mauvais alignement, pas de LVM, XFS/Reiser un peu dépassés, noatime vs relatime, discard automatique aujourd'hui, /tmp en RAM qui ne change quasi rien, …).
# LVM ?

Posté par Misc (site web personnel) le 09 septembre 2012 à 12:04. Évalué à 6.

Je suis surpris que personne ne parle de LVM. Moi, en général, je fais juste / et /home ( et la swap ) en LVM, en mettant 8 et 20g, et quand j'ai besoin de plus, je retaille. Du coup, ça implique d'avoir un /boot hors du lvm ou de faire confiance à l'initrd ou grub2 pour booter en lvm directement ( et je suis un peu frileux, je laisse l'installeur faire le choix par défaut ).

Et on va me dire "pourquoi un /home de 20g si tu as surement plus ?". Parce que les données, c'est comme les gaz, ça prends toute la place qu'on leur donne. Si je me mets un /home de 500g, j'ai du coup besoin de faire un backup de 500g.
Avec du lvm, si j'ai des besoins, je rajoute à chaud ce qu'il me faut, à grand coup de lvextend et resize2fs.

Et je sépare pas toujours /var/ /usr/, /usr/local, /opt/. J'ai franchement pas vu trop l’intérêt au fil des années. Si /var est plein parce que les logs prennent toute la place, bah, avoir de la place sur /usr va pas m'aider. Si jamais tout est plein, je peux me logger quand même via un ssh. Donc au final, je pense qu'avoir des emmerdes de temps en temps ( car j'ai eu des partoches pleines comme tout le monde ) est un compromis acceptable par rapport au temps que je passe pas à optimiser à mort les partitions ou à me dire "ça, c'est plein, faut que j'agrandisse la partition"

Mais le fait de tout mettre dans /usr va peut être me faire changer d'avis, si on peut du coup faire des systèmes à peu de frais en dupliquant /usr entre des containeurs ( ceci dit, avec mount -o bind, on a pas besoin de partition non plus ).
- [^] # Re: LVM ?
  
  Posté par Marotte ⛧ le 09 septembre 2012 à 13:28. Évalué à 3.
  
  Je suis surpris que personne ne parle de LVM
  
  Toi t'as pas lu tous les commentaires, notament celui-ci qui extrêmement pertinent, parce que c'est le mien ;)
  
  Et je sépare pas toujours /var/ /usr/, /usr/local, /opt/. J'ai franchement pas vu trop l’intérêt au fil des années. Si /var est plein parce que les logs prennent toute la place, bah, avoir de la place sur /usr va pas m'aider.
  
  Je suis loin d'être un expert mais l'avantage c'est pas d'éviter de remplir la partition racine (/) ?
  - [^] # Re: LVM ?
    
    Posté par Misc (site web personnel) le 09 septembre 2012 à 15:40. Évalué à 5.
    
    Toi t'as pas lu tous les commentaires
    
    j'ai vu, mais j'avais pas lu tout le commentaire, tu as caché lvm à la fin :p
    
    Je suis loin d'être un expert mais l'avantage c'est pas d'éviter de remplir la partition racine (/) ?
    
    Ben remplir / en soit, ça veut pas dire grand chose. En fait, l'impact, c'est que si / est plein, alors tu peux supposer que tout en dessous est plein aussi, et donc, tu peux pas écrire dans /tmp, /var, /home sauf si ils sont séparés. Donc au final, il faut se dire "quel répertoire je suis susceptible de remplir et quel impact ça va avoir".
    
    Remplir tout ton disque, ça peut empêcher divers choses :
    - plus de logs en local
    - des daemons qui se relance pas ( pas moyen d'écrire dans /var/lock ) ( même si avec /run en tmpfs, ç'est plus un souci )
    - des opérations diverses qui échouent ( genre plus de place dans /tmp, gcc va pas marcher )
    
    Donc à partir de la, tu évalues. Et par exemple, si tu fais un /var séparé, tu va toujours avoir le souci d'avoir des risques sur le fait d'avoir trop de log en cas de souci. Pire encore, tu va quand même impacter ta base postgresql si l'espace est partagé ( ie, pas de /var/lib/postgresql séparé ). Et tes daemons vont quand même se planter au lancement.
    
    Alors qu'avec un / assez grand, tu évites pas les emmerdes, mais tu évites la gestion. Si tu veux éviter les emmerdes, c'est pas limiter l'espace qu'il faut faire, c'est surveiller la consommation ( munin, cacti, nagios, etc ).
    
    Ensuite, je sais qu'il y a des gens qui préfèrent une autre façon de faire, ils ont le droit, j'ai pas la vérité absolu :) ( et y a sans doute des cas ou un contrôle plus fin est meilleur au final )
# multiples partitions = sources de problemes

Posté par NeoX le 09 septembre 2012 à 16:03. Évalué à 7.

Pour des raisons de sécurité et de sûreté des données, il est préférable de créer des partitions pour /boot, /var, /tmp et /home (voire /opt pour ceux qui compilent des trucs pour leur système) distinctes de la partition racine /.

pour une machine desktop, la securité n'est pas un besoin vital.

et en faisant plein de partition, tu prend le risque que l'une d'elle soit pleine sans pouvoir t'en debrouiller.

au mieux je ferais un / et un /home pour le cas ou tu risquerais de reinstaller ton OS

si tu veux de la securité pour tes données, avec 2 disques durs faire un raid1, avec 3 disques faire un raid5, etc
# noatime sur /home

Posté par Cyril Chaboisseau (Mastodon) le 10 septembre 2012 à 08:25. Évalué à 1.

petite remarque sur l'utilisation débridée de noatime et en particulier sur /home

certains logiciels tels que les clients mail ont une utilisation de la date de dernier accès aux fichiers (mailbox en l'occurrence) et donc une telle option peut engendrer des comportements erratiques.

Donc avant de se jeter sur ces optimisations à la petite semaine qui au mieux feront gagner 1 à 2 secondes (et encore, j'en doute sur les machines actuelles), bien peser le pour et le contre et ne pas hésiter à débrayer tout ça si on rencontre des dysfonctionnement.

mes 2 cents
- [^] # Re: noatime sur /home
  
  Posté par Buf (Mastodon) le 10 septembre 2012 à 08:35. Évalué à 5.
  
  certains logiciels tels que les clients mail ont une utilisation de la date de dernier accès aux fichiers (mailbox en l'occurrence) et donc une telle option peut engendrer des comportements erratiques.
  
  Sérieusement, si c'est vraiment le cas (j'en doute), faut arrêter d'utiliser des logiciels écrits avec les pieds.
  
  La date d'accès, ça donne une information peu utile au final, parce qu'il peut y avoir pas mal de cas où un logiciel accède à un fichier (par exemple : backup ou indexation)
  - [^] # Re: noatime sur /home
    
    Posté par claudex le 10 septembre 2012 à 12:54. Évalué à 4.
    
    Sérieusement, si c'est vraiment le cas (j'en doute), faut arrêter d'utiliser des logiciels écrits avec les pieds.
    
    Regarde du côté de Postfix.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: noatime sur /home
      
      Posté par Buf (Mastodon) le 10 septembre 2012 à 13:46. Évalué à 4.
      
      Ok, j'exagère peut-être en disant "programmé avec les pieds".
      
      Toujours est-il que l'information apportée par le atime n'est absolument pas fiable (il faut faire la supposition qu'aucun processus externe "parasite" ne vienne lire le fichier), et un logiciel sérieux évitera autant que possible de se baser là-dessus.
    - [^] # Re: noatime sur /home
      
      Posté par Patrick Lamaizière (site web personnel) le 11 septembre 2012 à 21:33. Évalué à 3.
      
      Regarde du côté de Postfix.
      
      Jamais eu le moindre soucis avec noatime et postfix.
      
      (Ce qui ne veut pas dire qu'il n'y en a pas vu la diversité des configs possibles.)
      
      Une rapide recherche donne ça qui est intéressant ceci dit:
      http://archives.neohapsis.com/archives/postfix/2006-01/1916.html
      
      "Postfix uses atime (last read/execute) time stamps to decide when
      to update its "fast flush" logs, which are used by ETRN clients.
      When this breaks, Postfix will attempt to deliver all deferred mail
      that is listed in "fast flush" logs, whenever the flush daemon scans
      its logs. By default, this happens every 1000s."
      
      Bon…
      # zfs set atime=on jails/192.168.1.2
      
      les pixels au peuple !
- [^] # Re: noatime sur /home
  
  Posté par Sarcastic le 11 septembre 2012 à 21:29. Évalué à 2.
  
  certains logiciels tels que les clients mail ont une utilisation de la date de dernier accès aux fichiers (mailbox en l'occurrence) et donc une telle option peut engendrer des comportements erratiques.
  
  Ouais. En fait, au lieu de noatime, il vaut mieux mettre relatime (il me semble que c'est par défaut pour les noyaux suffisamment récents, mais pas certain). En gros, le temps d'accès n'est mis à jour que lorsqu'il y a écriture sur le fichier. Donc, c'est grosso modo le même gain de temps que noatime, sans planter mutt et consorts.