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)
# Mes commentaires...
Posté par Christophe Merlet (site web personnel) . En réponse au journal Un fstab bien configuré pour un ordinateur « de bureau ». Évalué à 10.
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 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)
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)
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…
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
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 !
À 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)