Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Je crois qu'on ne peux pas redimentionner une partition à chaud
Si, on peut redimensionner une partition à chaud sous certaines conditions. Mais une partition étant par nature constituée de blocs contigus, l'agrandir suppose qu'il y ait suffisamment d'espace derrière elle. Dans le cas contraire, il peut être nécessaire de déplacer ou supprimer la ou les partitions suivantes, ce qui ne peut être fait à chaud si cette dernière est en cours d'utilisation.
Avec LVM, on n'a pas cette contrainte car les volumes logiques n'ont pas besoin d'être constitués de blocs consécutifs.
Mais il faut distinguer le redimensionnement de la partition ou du volume et le redimensionnement de son contenu. Certains programmes comme Gparted font les deux en même temps, mais ce n'est pas le cas des programmes plus simples comme fdisk, parted ou gdisk qui ne s'occupent pas du contenu.
Les systèmes de fichiers usuels comme ext2, ext3, ext4, XFS peuvent être agrandis à chaud (montés) mais pas réduits à chaud. En revanche le nouveau système de fichiers btrfs peut être agrandi et réduit à chaud. Actuellement un système de fichiers XFS ne peut toujours pas être réduit du tout, même à froid.
Redimensionner un ensemble RAID est compliqué, il vaut mieux l'éviter. C'est pourquoi il est plus souple de créer un ensemble RAID supportant du LVM que plusieurs ensembles RAID. Ainsi on n'a pas besoin de redimensionner le RAID mais seulement les volumes logiques LVM à l'intérieur du RAID.
Dernière modification par raleur (03-09-2016 21:12:33)
Il vaut mieux montrer que raconter.
Hors ligne
stephgarg a écrit :peut-être que tu peux agrandir la partition /usr jusqu'à 30 Go
Pour un serveur web, je ne pense pas que ce soit nécessaire.
Dans ce cas, peut-être devrions-nous faire une suggestion contraire : reduire la même partition /usr à 10 Go ? Il me semble que cela peut être tout à fait suffisant pour la mise en place d'un serveur httpd (basé sur Apache, Nginx ou Lighttpd pour ne parler que les plus connus). A moins que notre ami klosius ait d'autre projets en paralléle pour son ordinateur... 
stephgarg a écrit :autant je suis plus sceptique quant à l'"utilité" d'avoir le répertoire /usr elle aussi séparée
Cela permet par exemple de monter /usr en lecture seule la plupart du temps, ce qu'on ne peut pas encore faire avec la racine.
Hum, je dois faire trois remarques 
:
- En cas d'une partition /usr en lecture seule, il faudra prévoir d'autoriser les écritures (par l'intermédiaire de la commande 'mount -o remount,rw' sauf erreur de ma part) avant toute opération d'installation de nouveau(x) paquet(s) ou de suppression/purge/mise-à-jour des paquets déjà installés pour par la suite remettre le montage de /usr en lecture seule. Bon, j'imagine qu'on ne doit pas faire cela tous les jours mais, à la long, cela risque de devenir fastidieux et de provoquer des erreurs ou des omissions... à moins qu'il aurait une possibilité d'automatiser ces opérations.
- Je pense que le fait qu'on doit éviter de mettre une partition-racine / en lecture seule est dû au fait qu'il y ait quelques modifications de je ne sais quels fichiers dans le répertoire /etc (ou un de ses sous-répertoires) pendant le fonctionnement courant d'un système GNU/Linux. Quand j'aurais un moment et avec la commande 'find / -mount -mtime 7 -type f', je songerai à lister les fichiers situés dans la partition-racine et qui ont été modifiès pendant les 7 derniers jours (par exemple) même si, par la suite, je dois ignorer ceux qui ont été impactés par toute opération d'installation/suppression/purge/mise-à-jour de(s) paquet(s).
- Enfin, après lecture de la page C.2. L'arborescence des fichiers du manuel d'installation de Jessie et même si on y détaille pas plus que cela les raisons, ils semblerait qu'il est recommandé de ne plus avoir une partition /usr séparée de la partition-racine / car, et je cite, "cela pourrait provoquer des problèmes au démarrage". Notons que cela semble être très récent car ce conseil ne figure pas dans le manuel d'installation de Wheezy.
stephgarg a écrit :Par ailleurs, j'ai remarqué que tu as réservé 3000 Go pour ta partition /var soit 7 fois plus pour ta partition /home (400 Go)
Je soupçonne que c'est pour recevoir le contenu des sites web, bases de données... puisque c'est un serveur web. C'est un choix.
D'accord mais je ne suis pas complètement départi de mon étonnement car les 3000 Go me semblent tout de même très ambitieux pour un serveur personnel... Mais comme tu le dis, c'est un choix.
A bientôt.
Trois PC dont un fixe Sirius, un transportable Canopus et un miniportable Arcturus.
Sirius : Ryzen 7 3700X à 4,4 GHz, SDRAM DDR4 3,6 GHz de 32 Gio, 10 To de SSD dont 20% en PCIe 3.0 4x.
Canopus : Core i5-9600K à 3,7 GHz, SDRAM DDR4 3,0 GHz de 16 Gio, 5 To de SSD dont 20% en PCIe 3.0 4x.
Arcturus : Core i5-10210U à 1,6 Ghz, SDRAM DDR4 2,4 GHz de 8 Gio, 2 To de SSD SATA-3.
Hors ligne
sda3 et sdb3 --> 3995 GB --> RAID1 --> md1 --> 6 partitions logique
Partitions ou volumes logiques ? As-tu partitionné l'ensemble RAID (manuellement puisque partman ne le permet pas) ou l'as-tu utilisé comme volume physique LVM ?
3 TB --> /var
400 GB --> /var
Je suppose que l'une des deux est en fait pour /home.
si un des 2 disque dur tombe en panne et on le change pour un autre disque dur de la même capacité, ça dépend de la marque ça ne sera pas exactement la même capacité
C'est vrai. La capacité utile d'un ensemble de RAID en tient compte en prenant un peu de marge par rapport à la taille de ses membres car les partitions n'ont pas toujours exactement la même taille. La différence de capacité exacte entre deux disques de capacité similaire est généralement faible, mais j'ai eu un disque vendu pour 160 Go qui avait une capacité réelle de 164 Go. Pas évident de le remplacer par un disque qui aurait une capacité juste de 160 Go. Comme les fabricants ne peuvent normalement pas annoncer une capacité commerciale supérieure à la capacité réelle (ce serait une fraude), on limite le risque si on utilise le disque à sa capacité commerciale.
Il vaut mieux montrer que raconter.
Hors ligne
En cas d'une partition /usr en lecture seule, il faudra prévoir d'autoriser les écritures (par l'intermédiaire de la commande 'mount -o remount,rw' sauf erreur de ma part) avant toute opération d'installation de nouveau(x) paquet(s) ou de suppression/purge/mise-à-jour des paquets déjà installés pour par la suite remettre le montage de /usr en lecture seule.
Tu as entièrement raison, et comme tu le soupçonnes il y a bien moyen d'automatiser le remontage grâce à des options de dpkg ou apt (je ne me souviens plus) permettant d'exécuter des commandes avant et après les opérations sur les paquets.
Je pense que le fait qu'on doit éviter de mettre une partition-racine / en lecture seule est dû au fait qu'il y ait quelques modifications de je ne sais quels fichiers dans le répertoire /etc (ou un de ses sous-répertoires) pendant le fonctionnement courant d'un système GNU/Linux.
En effet. J'ai vu qu'il y a des développement en cours pour pouvoir laisser /etc en lecture seule en fonctionnement normal (sauf quand il faudra installer, modifier ou supprimer un fichier de configuration bien sûr, comme pour /usr) mais je ne sais pas où ça en est.
ils semblerait qu'il est recommandé de ne plus avoir une partition /usr séparée de la partition-racine / car, et je cite, "cela pourrait provoquer des problèmes au démarrage". Notons que cela semble être très récent car ce conseil ne figure pas dans le manuel d'installation de Wheezy.
Curieux car ce conseil est justement devenu en grande partie obsolète à partir de Jessie. Il était justifié auparavant car les montages définis dans /etc/fstab sont exécutés assez tard dans la séquence d'init, notamment bien après le démarrage d'udev dont les règles (pas forcéments installées par udev mais aussi par d'autres programmes, donc ne pas lui jeter la pierre) peuvent faire appel à des programmes situés dans /usr ou utilisant des fichiers situés dans /usr. Cela n'aurait pas dû arriver, mais c'est arrivé et il faut faire avec. La solution immédiate consistait à ne pas séparer /usr, ce que l'installateur Debian ne propose plus depuis un certain temps dans son mode assisté. D'autant plus que les raisons historiques de cette séparation sont elles-mêmes obsolètes.
Jessie a résolu le problème en montant /usr en même temps que la racine dès la phase de l'initramfs, avant la séquence d'init. J'ai écrit "en grande partie" car le problème persiste si le système utilise un noyau personnalisé sans initramfs, le noyau seul n'étant capable de monter que la racine avant de lancer la séquence d'init. Il est à noter que ne pas utiliser d'initramfs a d'autres limitations concernant la racine : absence de support des UUID et labels, du RAID logiciel moderne, de LVM, du chiffrement, pas de shell de secours en cas d'échec du montage de la racine mais directement un kernel panic...
Dernière modification par raleur (03-09-2016 22:29:13)
Il vaut mieux montrer que raconter.
Hors ligne
" il n'y a pas de question idiote, seulement une réponse idiote" Albert Einstein
Hors ligne
Par contre je reste toujours dans le doute si mon premier disque dur tombe en panne, est-ce que je pourrais rebooter avec mon 2ème? .
J'avais déjà répondu à cette question dans le message #3.
Le RAID 10 n'était qu'une suggestion, pas une recommandation. Il vaut mieux n'utiliser que ce qu'on comprend et connaît.
A ce sujet, si tu n'avais jamais utilisé LVM auparavant je te recommande de te familiariser avec ses concepts et ses commandes pour manipuler les volumes.
Il vaut mieux montrer que raconter.
Hors ligne
" il n'y a pas de question idiote, seulement une réponse idiote" Albert Einstein
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Trois PC dont un fixe Sirius, un transportable Canopus et un miniportable Arcturus.
Sirius : Ryzen 7 3700X à 4,4 GHz, SDRAM DDR4 3,6 GHz de 32 Gio, 10 To de SSD dont 20% en PCIe 3.0 4x.
Canopus : Core i5-9600K à 3,7 GHz, SDRAM DDR4 3,0 GHz de 16 Gio, 5 To de SSD dont 20% en PCIe 3.0 4x.
Arcturus : Core i5-10210U à 1,6 Ghz, SDRAM DDR4 2,4 GHz de 8 Gio, 2 To de SSD SATA-3.
Hors ligne