Est-ce vraiment mauvais d'installer Linux sur une seule grande partition ?

Il y a deux raisons principales pour le cloisonnement :

1. Pour éloigner les données statiques des données non statiques
2. Pour éloigner les données publiques des données privées

La première raison est la plus évidente - vous devez isoler les zones qui se rempliront de fichiers de celles qui ne le feront pas, et vous voulez particulièrement protéger /, pour éviter un système non amorçable. Par exemple, le répertoire /var est généralement l'endroit où les fichiers journaux seront stockés (var signifie "variable") et c'est pourquoi /var a tendance à être monté sur une partition séparée de /.

La deuxième raison ci-dessus est moins citée (je l'ai entendue pour la dernière fois lors d'un cours sur Veritas Volume Manager il y a environ 15 ans) et elle n'est vraiment pertinente que pour les systèmes où de nombreuses personnes se connectent et effectuent des tâches.

Le partionnement efficace est un art, et c'est peut-être la raison pour laquelle certains administrateurs système vont un peu trop loin (IMO). Non seulement vous devez connaître le système de fichiers à fond, mais vous devez également connaître l'utilisation prévue. Personnellement, je pense que c'est une approche plutôt démodée qui devient de moins en moins pertinente pour la façon dont les serveurs sont utilisés aujourd'hui.

En tant que développeur de logiciels, j'en ai particulièrement assez que le département des opérations construise des machines virtuelles avec des schémas de partitionnement irréfléchis qui limitent sévèrement la taille de /tmp, /home, /var et /, indépendamment de l'espace disque total disponible, mais qui ne montent pas séparément des choix évidents comme /usr ou /opt. Ces machines placent généralement ce qui reste de l'espace disque que vous avez demandé dans un volume "/stuff" dans lequel vous finissez inévitablement par tout installer et faire des liens symboliques, mais ce n'est pas une consolation. Le résultat net est que nous passons souvent plus de temps à mélanger des fichiers et à envoyer des courriels d'avertissement qu'à faire du vrai travail.

Il n'y a rien d'intrinsèquement "mauvais" à avoir une seule partition. Sur n'importe quel système, vous devriez surveiller de manière proactive l'utilisation de votre disque, et employer des stratégies de gestion raisonnables (par exemple, rotation des journaux, quotas sur les répertoires personnels), donc la seule vraie question est : de combien de systèmes de fichiers séparés voulez-vous vous soucier ?

Je dirais donc : si vous n'êtes pas sûr à 100% de votre capacité à partitionner le système de manière efficace pour votre cas particulier, ne le faites pas du tout. .

Cela permet de sauvegarder, restaurer ou réinstaller le système d'exploitation indépendamment des données de l'utilisateur. Cela vous donne la liberté, l'indépendance et la sécurité.

1. Il est beaucoup plus facile de migrer vers une autre distribution Linux tout en préservant la majorité absolue des données de l'utilisateur.

2. Il est facile de revenir sur des mises à jour boguées en appliquant la sauvegarde de la partition du système d'exploitation (le double démarrage est nécessaire). Cette sauvegarde peut même être assez ancienne - vous pouvez l'appliquer et mettre à jour ultérieurement vers la version stable.

3. Il est facile de revenir à la version précédente du système d'exploitation si vous n'aimez pas la "mise à niveau majeure" récemment appliquée (le double démarrage est nécessaire).

Pour tirer le meilleur parti de cette approche, vous devriez également configurer le double démarrage (peut également être CentOS/CentOS), de sorte que vous puissiez écraser une partition du système d'exploitation tout en exécutant le système d'exploitation à partir d'une autre. Et, bien sûr, vous devez sauvegarder la partition du système au moins une fois tous les quelques mois.

IMHO, cela dépend entièrement de vous. Considérez d'abord quelques éléments, bien qu'entièrement soit quelque peu relatif.

• ce système sera-t-il administré fréquemment ?
• Ce système sera-t-il utilisé par un ou plusieurs utilisateurs ?
• Ce système servira-t-il de bureau ou de serveur, ou les deux ?

Puisque l'on peut considérer (presque) n'importe quel répertoire comme un point de montage, il faut également tenir compte de ce qui contient des données peu croissantes et de ce qui contient des données croissantes.

Vous seriez surpris de voir à quel point un système linux (dont les données augmentent quelque peu) a besoin de peu de ressources pour fonctionner et combien de ressources sont consommées par les données croissantes (typiquement /var /opt /home /srv).

Cela dépend également de la façon dont vous définissez l'utilisation de ce système, qui décrit les exigences en matière de partitionnement. L'utilisation de LVM inclut.

Un système de bureau typique a besoin d'environ 20 Go pour l'installation de nombreux logiciels, le reste étant affecté à un /home dédié. LVM entraîne une surcharge mineure sur votre système et, dans ce cas particulier, n'est pas d'un grand bénéfice. Bien que les opinions puissent différer.

Sur un serveur, il est moins probable que les logiciels installés soient aussi dynamiques que sur un système de bureau. Il est également plus sage d'avoir des points de montage réels pour les composants typiques du système de fichiers tels que /tmp /var /usr /home /opt /srv L'utilisation de LVM est ici recommandée pour ne pas dire obligatoire.

Cela offre une grande modularité à votre système, et permet également de faire des choses stupides comme cloner cette partition dans une VM par exemple. Ou créer une sauvegarde au niveau des blocs en utilisant dd.

Sur la base d'une certaine expérience, voici quelques remarques. Envisagez également d'avoir plusieurs points de montage pour un meilleur contrôle, l'affectation d'un disque rapide ou lent à un point de montage peut faire toute la différence et augmenter sensiblement la rentabilité.

Mounpoint /

• 1GB ( si vous utilisez des points de montage séparés pour /var /usr /opt /home /tmp )
• +10 ou même +20 Go si vous l'utilisez comme un système de bureau avec un /home séparé.

si vous utilisez le point de montage /home

• attribuer tout l'espace libre si utilisé, /home ne

si vous utilisez le point de montage /opt

si vous utilisez le point de montage /usr

• C'est une question délicate qui dépend énormément de la base de logiciels installés.

si vous utilisez le point de montage /var

• C'est une question délicate qui dépend énormément de la base de logiciels installés.
• par exemple, les bases de données écrivent leurs données ici sur les systÃ?mes basés sur Debian, si ce n'est tous les Linux
• avoir un /var/tmp séparé n'est pas déraisonnable

si vous utilisez le point de montage /tmp

• considère que tmpfs existe et alloue /tmp à la RAM
• considérer que certaines applications peuvent écrire beaucoup de données ici

Je me demande, tout d'abord, pourquoi vous posez cette question ici, en tant que biologiste qui se dispute avec un administrateur système apparemment compétent concernant les points les plus fins du partitionnement du disque dur ! (sans vouloir vous offenser, je me demande simplement pourquoi vous ne faites pas confiance à votre administrateur système).

Alors, quelques observations :

• 1,3 To n'est plus un gros disque. 2 To est une taille de disque SATA plus ou moins standard dans le monde des ordinateurs de bureau de nos jours.

• il est peu probable qu'une installation de n'importe quelle distribution Linux nécessite plus de 100 Go. Il est certain que la taille de / (root) et (swap) devrait être facilement déterminée comme un nombre limité par le haut en les surdimensionnant généreusement (pour root) ou par les directives de configuration du système (swap).

• le point de montage pour /home devrait pointer vers quelque chose d'autre sur votre serveur RAID 40TB. Il n'est pas nécessaire que ces données, les répertoires personnels des utilisateurs, se trouvent quelque part sur ce périphérique racine. Le fait de les placer sur le serveur RAID vous offre probablement une meilleure protection de toute façon. De plus, il s'agit très probablement d'une installation NAS facilement extensible, alors que le petit RAID intégré au boîtier du serveur ne l'est probablement pas.

• vous devriez probablement mettre vos logiciels spéciaux dans une partition séparée (point de montage pour /usr/local/bin etc.) afin de pouvoir les préserver à travers les mises à jour du système d'exploitation et les effacements de la partition racine. Sinon, vous serez confronté à la possibilité de devoir réinstaller vos applications logicielles "spéciales" après une mise à jour/un correctif/quelque chose.

• si vous voulez vous préoccuper de l'administration de votre système, je poserais une autre question : quel est le processus de reprise après sinistre après que le bâtiment ait pris feu et que les serveurs et les boîtes RAID aient été détruits ? À moins que les données dont vous vous souciez ne restent entièrement dans votre tête, c'est une question que chaque utilisateur devrait poser à ses informaticiens/administrateurs. La stratégie devrait inclure des questions telles que "comment allons-nous répliquer le matériel dont nous avons besoin" et "combien de temps cela prendra-t-il avant que nous puissions être de nouveau opérationnels". Une discussion sur la virtualisation de vos serveurs pourrait aider à résoudre les problèmes liés aux dépendances matérielles et à remettre les choses en marche sans avoir à reconfigurer votre système d'exploitation (puisqu'il pourrait être configuré pour fonctionner dans un environnement de périphérique "souple" qui ne change pas, même si le matériel sous-jacent est complètement différent).

• De même, vous pouvez vous demander quelle est la stratégie de protection des données des utilisateurs contre les pertes de données dues aux programmes et aux erreurs des utilisateurs. L'enregistrement d'un fichier vide par-dessus le très bon brouillon de votre document de recherche, ou le fait qu'un utilisateur tape la mauvaise commande (rm -rf * par exemple) entraînera une perte de données aussi sûrement qu'un tremblement de terre, un incendie ou tout autre dommage physique. Les solutions pour la récupération de fichiers individuels sont un peu différentes (ou peuvent l'être !) de celles qui sont les plus utiles pour la reprise après sinistre globale.

-

Vous n'êtes pas obligé d'installer les logiciels dans /usr/local, vous pouvez installer tous les logiciels dans un préfixe différent, qui peut être dans /home. La plupart des logiciels peuvent faire cela lorsque vous les compilez à partir des sources, en exécutant par exemple ./configure --prefix=/home/bin

Comme vous êtes biologiste, vous pourriez être intéressé par de nombreux logiciels qui ne sont pas correctement empaquetés dans un rpm ou un deb et vous devrez de toute façon les compiler à partir des sources.

Je suis administrateur système pour un système HPC avec beaucoup de biologistes parmi nos utilisateurs, nous installons tous les logiciels qu'ils demandent sous un système de fichiers /apps/, donc je sais qu'il est possible de le faire pour la plupart des logiciels, cependant, parfois cela peut être très difficile. Pour résoudre ce problème, mes collègues et moi avons écrit sur un outil appelé EasyBuild (Gratuit et open source) Il peut compiler et installer un logiciel à partir de la source, et l'installer dans un dossier différent, et créer automatiquement un fichier d'installation. module environnement pour vous, de sorte que vous pouvez avoir 2 versions différentes du même logiciel installé, et n'avoir aucun conflit.

Jetez un coup d'œil à notre liste des paquets nous pouvons les installer avec une seule commande, en tant que biologiste vous pourriez en reconnaître beaucoup ;-)

Clause de non-responsabilité : Je suis un développeur d'EasyBuild.