Re: /home et /(root) partition ou répertoire ?

Bonjour,

Le 28 sept. 2025 à 09:47, Michel Verdier <mv524@free.fr> a écrit :

Le 27 septembre 2025 hamster a écrit :

Je ne connais pas la raison historique, mais je pense qu’a l’époque c’etait
plutot des gros ordis dans des universités et du coup la partition racine et
la partition /home sur des disques différents.

Pas seulement les universités, et même sur des serveurs différents (thin
client, nfs, tout ça). Je pense que ça se fait toujours.

Le fait de faire une partition /home séparée permet de bien mieux gérer la
place réservée au système. Mais alors il faut penser a mettre la partition
/home avec 0 % réservés au système.

En fait de séparer ne protège pas complètement. Certes les applis user ne
vont pas créer des fichiers dans l'espace système, mais des logs oui et
ça peut saturer. J'ai déjà eu le cas. Et des logs remplies ça bloque
tout. Du moins avec syslog (rsyslog). Avec journald je ne suis pas sûr.

Tout à fait, c’est pourquoi nous avons choisi de ne pas seulement mettre /home sur une partition séparée mais d’une partition dédiée à tout débordement constaté sur le FS root (chez nous /Donnees) qui peut accueillir :

Les /home, /opt, ou autre
Les /var/lib/… qui dérobent (p.e. docker, snap, postgesql, …)
Un espace de stockage de données nécessitant un accès rapide. Par exemple cet espace est utilisable pour les traitements lourds (données satellite, statistiques, …) qui, dans un historique de données seront stockées sur un NAS externe et montées par NFS (ou autre)
Autres

Pour ne pas perturber les configurations par défaut des paquets on remonte les répertoires déplacés avec BIND dans le /etc/fstab. Par exemple :

/Donnees/home /home none bind 0 0

/Donnees/var/lib/docker /var/lib/docker none bind 0 0
/Donnees/var/lib/postgresql /var/lib/postgresql none bind 0 0

Bien entendu tout ça se fait hors exploitation en arrêtant tous les services visés et/ou en montant les FS de la VM sur une VM de travail et en faisant un chroot sur les FS de la VM à modifier. Une fois tout ça effectué, les paquets touchés ne voient rien et ne risquent pas d’encombrer le FS root et un FS tiers saturé ne plantera pas la VM (ou physique).

Pour les traitements de données très volumétriques (images satellites par exemple) le principe est de procéder comme suit :

Copier les données à traiter sur le FS /Donnees/Spool
Configurer son logiciel pour écrire ses fichiers intermédiaires aussi sur /Donnees
Lancer le traitement
Archiver le(s) résultat(s) sur le NAS

Tout ça parce qu’il n’y a pas que les /var/lib qui peuvent encombrer le FS root mais aussi les fichiers temporaires utilisés par les logiciels de traitement…

Bien entendu il ne faut pas oublier de sauvegarder l’ensemble des données système déplacée si on veut une restauration correcte.

Certains peuvent y voir une inspiration de ce qui est généralement fait sur les clusters de calcul. Ce n’est pas faux ;-) mais sans aller jusqu’au bout. Là le HOME de chaque utilisateur « monte » un répertoire de travail sur un NAS ultra-rapide (SSD) et un répertoire de stockage sur un autre espace NAS moins rapide.

Bonne journée

--

M Pierre Malard

Clé OpenGPG : https://keys.openpgp.org

  «Quand un Français dit du mal de lui, ne le croyez pas, Il se vante !»
                                           Édouard Pailleron
   |\      _,,,---,,_
   /,`.-'`'    -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'