À quel point est-il vraiment mauvais d'installer Linux sur une seule grande partition ?

Solution 1 :

Les principales raisons (historiques) du partitionnement sont :

• pour séparer le système d'exploitation de vos données d'utilisateur et d'application . Jusqu'à la sortie de RHEL 7, aucun chemin de mise à niveau n'était pris en charge. et une mise à jour de version majeure nécessiterait une réinstallation et ensuite avoir par exemple /home et d'autres données (d'application) sur des partitions séparées (ou volumes LVM) vous permettent de conserver facilement les données utilisateur et les données d'application et d'effacer la ou les partitions du système d'exploitation.

• Les utilisateurs ne peuvent pas se connecter correctement et votre système commence à échouer de manière intéressante lorsque vous manquez complètement d'espace disque. Plusieurs partitions vous permettent d'attribuer un espace disque réservé au système d'exploitation et de le séparer de la zone où les utilisateurs et/ou des applications spécifiques sont autorisés à écrire (par exemple, /home /tmp/ /var/tmp/ /var/spool/ /oradata/ etc.), atténuer le risque opérationnel d'utilisateurs et/ou d'applications qui se comportent mal.

• Quota. Le quota de disque permet à l'administrateur d'empêcher un utilisateur individuel d'utiliser tout l'espace disponible, perturbant le service à tous les autres utilisateurs du système. Un quota de disque individuel est attribué par système de fichiers, donc une seule partition et donc un seul système de fichiers signifie seulement 1 quota de disque. Les partitions multiples (LVM) signifient plusieurs systèmes de fichiers permettant une gestion plus granulaire des quotas. En fonction de votre scénario d'utilisation, vous souhaiterez peut-être, par exemple, autoriser chaque utilisateur 10 Go dans son répertoire personnel, 2 To dans le répertoire /data sur la baie de stockage externe et configurer une grande zone de travail partagée où n'importe qui peut vider des ensembles de données trop volumineux pour son répertoire personnel. et où la politique devient "plein est plein" mais quand cela se produit, rien ne casse non plus.

• Fournir des chemins d'E/S dédiés . Vous pouvez avoir une combinaison de disques SSD et de disques rotatifs et feriez bien de les traiter différemment. Ce n'est pas vraiment un problème dans un serveur à usage général, mais il est assez courant dans les configurations de base de données d'affecter également certaines broches (disques) à différentes fins pour éviter les conflits d'E/S, par ex. disque séparé pour les journaux de transactions, disques séparés pour les données de base de données réelles et disques séparés pour l'espace temporaire. .

• Démarrer Vous pouvez avoir besoin d'un /boot séparé cloison. Historiquement, pour résoudre les problèmes de BIOS avec le démarrage au-delà de la limite de 1024 cylindres, aujourd'hui plus souvent une exigence pour prendre en charge les volumes chiffrés, pour prendre en charge certains contrôleurs RAID, les HBA qui ne prennent pas en charge le démarrage à partir du SAN ou les systèmes de fichiers non immédiatement pris en charge par le programme d'installation, etc.

• Réglage Vous pouvez avoir besoin de différentes options de réglage ou même de systèmes de fichiers complètement différents.

Si vous utilisez des partitions dures, vous devez plus ou moins bien faire les choses au moment de l'installation, puis une seule grande partition n'est pas la pire, mais elle s'accompagne de certaines des restrictions ci-dessus.

En règle générale, je recommande de partitionner votre volume principal en tant que un seul grand volume physique Linux LVM puis créer des volumes logiques qui correspondent à vos besoins actuels et pour le reste de votre espace disque, laissez non attribué jusqu'à ce que vous en ayez besoin .

Vous pouvez ensuite étendre ces volumes et leurs systèmes de fichiers selon vos besoins (ce qui est une opération triviale qui peut être effectuée sur un système en direct), ou en créer d'autres également.

La réduction des volumes LVM est triviale mais souvent la réduction des systèmes de fichiers sur eux n'est pas très bien prise en charge et devrait probablement être évité.

Solution 2 :

Le concept d'utilisation de plusieurs partitions est qu'une partition complète au mauvais endroit ne fera pas fonctionner l'ensemble du système de manière inattendue.

Considérez un processus sur la machine remplissant un fichier journal assez rapidement jusqu'au point où il n'y a plus d'espace libre disponible. Sur une machine à partition unique, cela pourrait alors, par exemple, empêcher le système d'écrire de nouvelles données dans /tmp. S'il y a un autre processus qui voudrait écrire dans /tmp, il se terminera probablement avec une erreur, provoquant un comportement inattendu.

Cela peut être évité si vous utilisez des partitions différentes pour les endroits où les utilisateurs ou les processus écrivent normalement (/home, /var, /tmp).

Je vous recommande de vérifier sur votre ancien serveur quels dossiers ont tendance à devenir volumineux. Vous pouvez le faire sur la ligne de commande avec

du -h -d 1 / 2> /dev/null

Vous verrez où le plus de données sont accumulées et concevoirez votre prochain système de manière appropriée. Le "-d 1" limite la sortie à un seul niveau de profondeur de dossier, ce qui la rend plus lisible.

Solution 3 :

Le principal problème d'avoir une seule grande partition est qu'en remplissant le système de fichiers, il est possible qu'aucune connexion ne soit plus possible.

L'utilisateur root a son dossier personnel (/root ) en dehors de /home à cause de ce. Si le système de fichiers est rempli dans certaines circonstances, même root ne peut pas se connecter et ne peut pas réparer le système.

C'est la raison pour laquelle vous créez normalement des points de montage séparés pour /var , /tmp et /home pouvoir se connecter au moins en tant que root pour réparer le système lorsqu'une des autres partitions est remplie.

Solution 4 :

À mon humble avis, avoir une partition comme / est tout à fait raisonnable.

Mais vous pouvez utiliser lvm (gestionnaire de volumes logiques). Utilisez tous les disques en tant que groupe lvm, mais créez de petits disques logiques pour /,/home,/usr et tout ce que votre administrateur système préfère. Ensuite, mettez en place une surveillance, que vous savez, lorsque votre système commence à être plein et développez les disques dont vous avez besoin. lvresize et resize2fs sont des outils en ligne et vous pouvez effectuer une extension sans redémarrer le serveur. Cependant, vous ne pouvez pas réduire les disques, vous devez donc commencer raisonnablement petit et augmenter là où vous en avez besoin.

Solution 5 :

Il y a des problèmes minimes autour de la configuration d'une grande partition unique de Linux, mais cela a de grandes récompenses.

Changer la disposition d'une partition est une chose un peu difficile et risquée, que vous ne pouvez souvent pas faire sans de longs temps d'arrêt.

Son seul avantage est que vous bénéficiez d'une certaine protection contre les problèmes de disque plein. Mais vous trouverez ces problèmes beaucoup souvent. Imaginez la situation, si l'une de vos partitions est pleine, et vous ne pouvez pas utiliser l'espace sur les autres partitions, même si elles sont presque vides !

Certains administrateurs système professionnels ont une opinion totalement différente à ce sujet. Ils disent que le fait d'avoir plusieurs partitions peut rendre votre système plus fiable et vous devez savoir avant votre partitionnement, quelle sera la taille de vos partitions. À mon avis, cela ne peut tout simplement pas être dit, c'est un terrible inconvénient pour la flexibilité du système, et leur véritable motivation est qu'ils aiment simplement jouer avec les cartes de partition .

Il existe un système simple nommé lvm, qui permet de déplacer/redimensionner à la volée des "partitions" (dans sa terminologie, des volumes). Mais sur un seul serveur de département local, à mon humble avis, ce n'est normalement pas nécessaire.