Bonjour,
> Le 28 sept. 2025 à 09:47, Michel Verdier <[email protected]> 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 <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'
