Vendez-moi le cloisonnement

En réponse à :

Il semble que le partitionnement augmente considérablement la probabilité de remplir une partition alors que les autres ont beaucoup d'espace libre.

Sur une machine Linux, LVM (logical volume management) est utilisé pour éviter cela. La plupart des systèmes de fichiers permettent le redimensionnement (certains même en ligne). Je crée différentes partitions pour différents usages et je les formate avec différents systèmes de fichiers (par exemple : xfs pour les gros fichiers de téléchargement que je peux rapidement supprimer). Besoin de plus d'espace ? Montez un nouveau disque, déplacez-y les données, puis montez-le à l'endroit où se trouvaient les données. Cette solution est totalement transparente pour les utilisateurs et les applications.

Avec LVM, vous pouvez ajouter des disques ou des partitions au groupe de volumes, puis créer des volumes logiques dans ce groupe. Si vous laissez de l'espace libre dans le groupe de volumes, vous pouvez alors agrandir les partitions qui se remplissent. Si le système de fichiers le prend en charge (ext3, ext4, reiserfs), vous pouvez réduire une partition que vous avez trop allouée.

Par exemple : créer une partition de démarrage sur /dev/sda1 créer une deuxième partition (non formatée) /dev/sda2

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

Lorsque vous avez besoin de plus d'espace sur /downloads (alors que le système de fichiers est monté) :

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

Vous disposez maintenant d'une partition de téléchargement de 150 Go. Idem pour la maison. En fait, je viens de redimensionner une "partition" ext4 lvm aujourd'hui. D'un autre côté, les volumes logiques ne sont pas vraiment des partitions et ce que vous dites sur les partitions de mauvaise taille correspond à mon expérience personnelle (plus d'ennuis qu'elles n'en valent).

Le schéma de partitionnement traditionnel d'Unix est définitivement une pratique de la vieille école qui n'est plus aussi utile qu'elle l'était autrefois. À l'époque où le temps de fonctionnement d'un système Unix se mesurait en années, et où des dizaines ou des centaines d'utilisateurs s'amusaient avec des shells, monter /usr en lecture seule était un moyen utile de protéger le système. Aujourd'hui, remonter les systèmes de fichiers pour les patcher semble plus laborieux et moins utile.

Dans mon université, au bon vieux temps, les clusters Unix avaient des systèmes de fichiers en lecture seule avec les outils Unix standard, et les applications complémentaires se trouvaient dans /usr/local, qui était un système de fichiers NFS et plus tard un système de fichiers AFS. Il s'agissait en partie d'une question de commodité... qui voulait recompiler des logiciels sur une douzaine d'ordinateurs de la grappe alors qu'il était possible d'exécuter des applications sur un réseau à grande vitesse de 4 ou 10 Mb ? Aujourd'hui, avec des gestionnaires de paquets décents et beaucoup de disques bon marché, ce n'est pas si grave.

Je pense que les processus de pensée ont commencé à changer pour moi sur les boîtiers Sun avec Veritas Volume Manager vers 1999, ce qui a considérablement réduit le seuil de douleur pour le déplacement des disques.

Aujourd'hui, lorsque je pense partitionnement, je pense protection des données et performances. Exemple illustratif :

• Le SAN de niveau 1 est très rapide, très disponible (5 9), répliqué et très coûteux. Les bases de données critiques ou les journaux de transactions y sont hébergés.
• Le SAN de niveau 2 est rapide, disponible (4 9) et cher. Les applications ou les données moins prioritaires y sont hébergées.
• Le SAN de niveau 3 est disponible (4 9), à bas prix. Les éléments qui ne sont pas sensibles aux performances y sont hébergés.

Ces considérations s'appliquent également à Windows. Nous avons un serveur SCCM qui gère environ 40 000 clients. La base de données et les journaux sont sur des disques IBM DS8000 de très grande qualité. Les progiciels se trouvent sur un EMC Celerra avec de grands disques SATA lents qui coûtent 60 % de moins par gigaoctet.

(En supposant qu'un seul grand disque soit disponible), je mets home y var sur des partitions séparées pour éviter le problème du "fichier [utilisateur|log] incontrôlable qui occupe tout l'espace" et pour permettre des mises à niveau faciles du système d'exploitation sans toucher à la maison, mais laissez le reste ensemble.

Sur du matériel plus ancien, il était parfois nécessaire de disposer d'un logiciel séparé de boot afin que l'image du noyau soit accessible au boot loader.

Je comprends que cette question n'est pas spécifique à un système d'exploitation, n'est-ce pas ?

Sous Windows, j'ai tendance à donner à toutes mes machines le moins de partitions possible, mais pas moins de deux - SYSTEM et DATA. Si la machine possède deux disques physiques, l'un (le plus petit) sera SYSTEM, l'autre DATA. S'il n'y a qu'un seul disque, je le divise en deux partitions.

La raison en est simple : lorsque je dois réinstaller la machine (et il y en aura une), je n'ai pas à me préoccuper du contenu de la partition SYSTEM - je me contente de la formater complètement et de l'installer proprement. Cela signifie bien sûr que mes documents (et de préférence mon bureau aussi) doivent être mappés à un dossier sur DATA, mais c'est facile à faire, surtout avec Vista et les versions ultérieures.

J'ai également essayé de créer d'autres sections (comme JEUX, MUSIQUE, FILMS, etc.), mais cela n'a fait que déborder certaines d'entre elles sur d'autres, créant plus de désordre que d'ordre.

Vous avez parlé d'un disque qui se remplit alors que l'autre a de l'espace libre. C'est l'une des raisons pour lesquelles je partitionne, parce que je peux m'assurer que certaines partitions ne se remplissent pas. ne faire le plein. Toutefois, en raison de l'ancienne gestion des quotas, il aurait fallu attribuer à tous les utilisateurs un quota de 0 sur les autres partitions, afin de s'assurer qu'ils ne commencent pas à cacher des fichiers s'ils parviennent à trouver un répertoire dans lequel ils peuvent écrire.

Quant à la simplification de la sauvegarde, si je connais la taille maximale de chaque partition, je peux m'assurer qu'elle tient sur une seule bande et qu'elle peut être effectuée en un temps donné.

En ce qui concerne la fiabilité, la seule chose à laquelle je peux penser est la surveillance - je peux plus facilement voir quand une partition donnée croît plus qu'elle ne le devrait, et me donner une raison d'y jeter un coup d'œil.

... Cela dit, nous sommes loin de l'époque où chaque utilisateur disposait d'un petit quota de 20 Mo sur une machine partagée. Certaines vieilles habitudes n'ont pas de sens, mais lorsqu'un processus devient fou et remplit /var, qui à son tour remplit /, et que les choses s'arrêtent, ce n'est pas si mal d'avoir une protection sur les machines de production.

Pour la maison, j'ai des partitions, mais c'est juste pour faciliter la gestion des systèmes d'exploitation installés.