Vendez-moi le cloisonnement

• Fsck plus rapide. Supposons que votre système tombe en panne, pour une raison ou une autre, et qu'au redémarrage il doive exécuter un fsck. Avec une partition très grande, ce fsck peut prendre une éternité et rien sur le système ne fonctionnera jusqu'à ce que le fsck de l'ensemble du système soit terminé. Si vous partitionnez le système de manière à ce que la partition racine soit assez petite, vous pourrez peut-être mettre le système en marche et faire fonctionner certains services de base en attendant que le fsck des volumes plus importants soit terminé.
  • si votre système a de petits disques, ou s'il n'y a qu'un seul service sur le système, cela n'a pas vraiment d'importance.
  • Avec les systèmes de fichiers journalisés, cela n'a pas d'importance la plupart du temps, mais parfois, même avec un système de fichiers journalisés, vous devez exécuter un fsck complet.
• Sécurité améliorée car vous pouvez monter un fs en lecture seule.
  • Par exemple, personne ne devrait avoir besoin d'écrire dans /usr dans le cadre d'une utilisation normale. Alors pourquoi ne pas simplement monter le système de fichiers pour qu'il soit en lecture seule. Le fait d'avoir des systèmes de fichiers en lecture seule lorsqu'ils n'ont pas besoin d'être écrits empêchera certaines attaques de script-kiddy, et peut vous empêcher de détruire des choses lorsque vous n'en avez pas l'intention.
  • Cela peut rendre la maintenance du système plus difficile, car vous devrez le remonter en lecture-écriture lorsque vous devrez appliquer des mises à jour.
• Amélioration des performances et des fonctionnalités pour un service ou une utilisation spécifique.
  • Certains systèmes de fichiers sont plus appropriés pour des services/applications spécifiques, ou vous permettent de configurer le système de fichiers de manière à ce qu'il fonctionne mieux dans certains cas. Vous avez peut-être un système de fichiers avec beaucoup de petits fichiers et vous avez besoin de plus d'inodes. Ou bien vous avez besoin de stocker quelques gros fichiers, des images de disques virtuels.

Je ne pense pas que la mise en place de nombreuses partitions soit quelque chose à faire pour chaque système. Personnellement, sur la plupart de mes serveurs Linux, je ne configure qu'une seule grande partition. En effet, la plupart de mes systèmes ont des disques de petite taille, sont à usage unique et jouent un rôle d'infrastructure (dns, dhcp, firewall, routeur, etc.). Sur mes serveurs de fichiers, je crée des partitions pour séparer les données du système.

Peut-on affirmer que le cloisonnement peut potentiellement accélérer les matériel, en raison du battement d'un disque lors du déplacement ou de la copie de données d'une partition à une autre sur le même disque ?

Je doute fort qu'un système bien partitionné ait un risque accru de défaillance.

L'une des raisons de séparer /home/ est que vous pouvez réinstaller le système d'exploitation sans craindre de perdre les données de l'utilisateur. De plus, il y a beaucoup de sécurité à avoir en montant tout en lecture seule ou en noexec. Si les utilisateurs ne peuvent pas exécuter de code partout où ils peuvent en écrire, c'est un vecteur d'attaque en moins.

Je ne l'utiliserais cependant que sur une machine publique, car l'inconvénient de manquer d'espace disque dans une partition et d'en avoir dans une autre est un sérieux désagrément. Il existe des moyens de contourner ce problème, comme le raid logiciel ou ZFS, qui devrait permettre de redimensionner dynamiquement les partitions facilement, mais je n'ai aucune expérience en la matière.

• Simplifier la sauvegarde

Vous pouvez faire des sauvegardes (via dumpfs ou similaire) des choses que vous voulez, pas des choses que vous ne voulez pas. dump(1) est un meilleur système de sauvegarde que tar(1).

• Remplir les partitions

C'est également un argument en faveur du cloisonnement. Les utilisateurs qui remplissent leur répertoire personnel ne détruisent pas le serveur, n'arrêtent pas le serveur web, n'empêchent pas les journaux de se produire, n'empêchent pas le super-utilisateur de se connecter, etc.

Cela vous permet également de déplacer de manière plus transparente une section de vos données (par exemple, /home) sur un autre disque : copiez-la, montez-la. Si vous utilisez un système qui permet les copies d'ombre / les instantanés, vous pouvez même le faire en direct.

On m'a toujours appris à garder /var sur une partition séparée, de sorte que si vous obtenez un fichier journal incontrôlable, vous n'encombrerez qu'une seule partition et non le disque entier. S'il se trouve sur le même espace que le reste du système et que vous remplissez votre disque à 100 %, il peut se bloquer et donner lieu à une restauration désagréable.

Tous les arguments avancés par Zoredache sont valables ; on peut chipoter un peu sur les détails (avoir une machine plus rapide pour pouvoir faire d'autres choses pendant qu'on vérifie d'autres systèmes de fichiers ne sert pas à grand-chose si la raison d'être du système est de fonctionner sur ces autres systèmes de fichiers) ; cependant, il s'agit toujours d'une justification a posteriori.

À l'époque de la vieille école, les systèmes de fichiers ne se trouvaient pas sur des partitions séparées, mais sur des disques distincts, car les disques étaient très petits. Pensez à 10 Mo(1). Vous aviez donc une minuscule partition /, un disque /var, un disque /usr, un disque /tmp et un disque /home. Si vous aviez besoin de plus d'espace, vous achetiez un autre disque.

Puis les "gros" disques de 50 Mo ont commencé à coûter moins cher que le programme lunaire, et il est soudain devenu possible de placer un système entier sur un seul disque avec une quantité utilisable d'espace utilisateur.

Néanmoins, la taille des disques étant faible par rapport à ce que l'ordinateur pouvait générer, isoler /var, /opt et /home de manière à ce que le fait d'en remplir un n'entraîne pas l'arrêt de l'ordinateur était toujours une bonne idée.

Aujourd'hui, dans une entreprise, je ne partitionne pas les systèmes d'exploitation. Les données sont partitionnées, surtout si elles sont générées par l'utilisateur, mais c'est souvent parce qu'elles se trouvent sur des matrices de disques à grande vitesse et/ou redondantes d'un genre ou d'un autre. Cependant, /var et /usr se trouvent tous dans la même partition que /.

Dans un environnement domestique, c'est la même chose - /home devrait probablement se trouver sur un disque/une baie séparé(e), afin que l'on puisse installer/mettre à jour/casser/réparer toutes les versions du système d'exploitation que l'on souhaite.

La raison en est que, quelle que soit la taille de votre /var ou /usr ou autre, vous vous tromperez de manière hilarante ou vous sur-commit. L'un de mes collègues de la vieille école ne jure que par le partitionnement, et il me fait toujours des reproches lorsqu'il doit subir un fsck de 180 jours sur un système que j'ai créé. Mais je peux compter sur les doigts d'une main le nombre de fois où quelque chose a rempli / et fait tomber le système, alors que je peux compter sur les doigts d'une main le nombre de fois où, depuis le début de l'année, j'ai été confronté à un système où quelqu'un a décidé que /var n'aurait jamais besoin de plus de (disons) 1 Go et s'est trompé, me laissant face à une /var pleine et à des centaines de Go libres ailleurs sur le système, qui auraient tout aussi bien pu être sur la lune pour tout le bien qu'ils m'ont fait.

Dans le monde actuel des grands disques, je ne vois pas de raison réelle de partitionner l'arborescence du système d'exploitation. Les données utilisateur, oui. Mais des partitions séparées pour /var et /usr et /var/spool etc etc ? Non.

(1) = et je sais que rien qu'en choisissant cette taille, je vais avoir quelqu'un qui va dire dans les commentaires 10MB ? Luxe. Pourquoi nos disques n'étaient que...