C'est aujourd'hui un sujet qui me sort beaucoup de guide peu satisfaisants qui m'amène à vous. Je cherche à mettre au point ma stratégie de partitionnement pour Linux, sur gros volume, en tant que single boot. Pour le moment ma cible est un laptop avec un seul disque dur, un mécanique de 1 TB, mais plus tard je m'occuperai de la même façon de mon desktop personnel qui a 2 SSD (125 GB et 250 GB) et 2 HDD (240 GB et 750 GB) dans le ventre...
Donc mon but est de trouver un compromis souple pour ces stratégies de partitionnement. J'ai quelques pré-requis :
Linux de la famille d'Arch. Pas Arch lui-même pour le moment parce que l'installation reste violente pour moi, mais j'ai testé Manjaro (pas fameux au niveau des paquets) et précédemment Architect, là je m'apprête à mettre Antergos à l'épreuve.
MBR. Parce que je n'ai rien qui rende l'UEFI indispensable.
/boot prévu dans sa propre partition en ext2 (plus rapide sans la journalisation). A voir pour la taille, j'avais pensé à 500 MB large. J'ai également prévu de le mettre spécifiquement sur sda1 (partition physique).
A voir si j'ai faux ici, mais swap prévu à 8 GB sur le laptop, double de la RAM et hibernation prévue. Sur le desktop, qui a 16 GB et où je ne compte pas utiliser l'hibernation, je pense que 4 GB devraient y suffire, mais dans les 2 cas il s'agirait d'une partition physique sda2.
/var s'il doit être dans sa propre partition, je pense le mettre en ReiserFS pour ses bonnes performances avec les petits fichiers. Je ne vois pas pour l'instant d'installateur qui gère le Reiser4 et c'est bien dommage...
Besoin d'un espace commun pour les différents utilisateurs de la machine, que ce soit pour Apache, MySQL, WINE, ou même les document communs.
Ne négligeons pas la possibilité d'installer de gros logiciels (y compris jeux)...
Je sais, je suis très exigeant.
Donc voilà, je cherche partant de là des stratégie adéquat pour mon partitionnement. Sachant que Antergos, comme Architect, est surtout un installateur pour le vrai Arch, et qu'à ce titre /tmp sera automatiquement monté en disque virtuel dans la ram. Donc il y a celui-là en moins à gérer.
Ce que j'ai déjà essayé sur le laptop...
... et trouvé insatisfaisant.
Il y a tout d'abord l'utilisation de 4 partitions toutes physiques : 500 MB pour /boot, 8 GB pour swap, 200 GB pour / et enfin le reste pour /home. Oui, ça a l'air de marcher plus ou moins (à part les déconnades de Manjaro mais ça c'est hors sujet) mais bon ça manque d'optimisation à mon goût pour certains dossiers comme /var.
Et surtout vient le problème de ce partage. Le laptop, bien qu'il n'y sera pas restreint, sera principalement utilisé pour du dev, avec la possibilité d'être fourni à un autre utilisateur pour faire son propre dev sur les sources. Je n'ai pas vraiment envie de passer par le calvaire d'un serveur FTP local comme je le fais actuellement sur Windows (pour rien en plus, j'avais pas besoin de le mettre en place sous Windows...) et en même temps si le serveur web local dépend de ma version des sources et qu'un autre utilisateur a une autre version, il ne pourra pas tester car le serveur web local ne verra pas les changements.
C'est pour ça que je suis revenu sur ma copie vis-à-bis des partitions, mais les guides et explications trouvées en cherchant n'étaient pas fameux. Soit c'est fait pour des systèmes de petite taille, soit c'est exactement la même config que celle déjà testée à part la taille des partitions, et jamais ça ne parle de ce problème de partition de partage, sauf le wiki d'Arch qui fait mention de cette possibilité (il l'appelle /data) mais ne précise en rien les choses à faire, comme les problèmes de droits qu'on va rencontrer par défaut (/data va appartenir à l'utilisateur "root"...)
Oula, c'est bien compliqué cela, je me serai limité à une partition swap, une partition racine et une partition /home Concernant le swap sur ton desktop, si tu ne feras pas d'hibernation et vu la taille de la ram (il faut déjà la remplir entièrement), 4 Go devraient suffire sans trop de problèmes. Ce n'est pas une mauvaise idée d'avoir isoler /boot, je n'y avais jamais pensé Enfin pour les dossiers où tu trouves que cela manque d'optimisation, quid de les mettre sur une autre partition créée par tes soins (ou plusieurs)?
Et pour le partage, il n'y a pas possibilité de créer une partition pour cela après l'installation et d'attribuer les droits à tous les utilisateurs?
Non seulement /boot est utile sur sa propre partition (et quand tu fais du multiboot multilinux, yen a qui le font, ça te permet d'avoir /boot en commun), mais si j'avais une table de partition GPT (donc pour l'UEFI), il serait indispensable d'en faire une pour /boot/efi, de ce que j'ai lu.
Pour la taille du swap j'ai aussi lu dans un guide des tailles conseillées en fonction de la situation (RAM, intention d'utiliser l'hibernation). Dans le cas d'un ordi ayant entre 2 et 8 GB de RAM avec intention d'hiberner, il est conseillé de mettre un swap 2 fois plus gros que la RAM. C'est le guide le plus détaillé que j'ai vu sur la question de la taille du swap.
Typhlos a écrit:
Enfin pour les dossiers où tu trouves que cela manque d'optimisation, quid de les mettre sur une autre partition créée par tes soins (ou plusieurs)?
Chargement, montage, lecture, écriture, journalisation... Ce genre de choses. Par exemple j'ai mentionné /var et ReiserFS, vu que /var est fait pour contenir une masse de petits fichiers, ReiserFS parait excellent justement puisqu'il est optimisé pour ce genre de contenus, au prix d'un délai plus long lorsqu'il faut monter la partition (mais ça c'est pas grave). Sur le papier on pourrait considérer /etc dans le même cas, mais je pense /etc trop petit pour justifier sa propre partition.
Mais comme je disais, peut-être qu'on peut travailler ça mieux.
Typhlos a écrit:
Et pour le partage, il n'y a pas possibilité de créer une partition pour cela après l'installation et d'attribuer les droits à tous les utilisateurs?
C'est quelque chose qui m'a été soufflé depuis. fstab permet même de préciser un utilisateur propriétaire de la partition montée quand on ne veut pas que ça soit root. A voir.
Mais en gros le problème qui demande cette partition de partage est l'utilisation de mêmes dossiers de données (et pas des copies) par plusieurs utilisateurs, y compris des utilisateurs systèmes (comme Apache) et humains (si on est amenés à bossé à plusieurs, ce qui arrivera sûrement avec ce laptop).
Toujours moi, toujours en train de bosser sur ces soucis de partitionnement.
Je cherche et ne trouve pas pour 'instant de ressource intéressante sur la partition partagée entre utilisateurs. Je trouve des partitions partagées entre OS multiples, mais ça ne m'intéresse pas, ça.
Le but est d'avoir un espace de documents et autres qui soit comment à tous les utilisateurs de la machine, qu'ils soient humains ou logiciels.
Pour le swap, tu dis que tu n'utilises pas l'hibernation. Mais au vu de la taille de ton disque, mieux vaut en prévoir un pour l'hibernation (donc de taille doublée par rapport à la RAM). Tu l'utiliseras sûrement un jour (même si ce n'est qu'une fois en 1 an) pour une raison X ou Y. Et tu seras bien content de pouvoir sauvegarder ton travail à ce moment là. Ne serait-ce même lorsque tu l'activeras par erreur. Et puis 16 Go sur 1To c'est vraiment pas ce qu'il y a de pire à faire.
La partition var ne sert véritablement qu'à écrire des données variables pour les programmes. C'est souvent utilisé pour les fichiers de logs. Mais pas souvent utilisé par l'utilisateur ou même l'administrateur. Et puis avec Arch, il est rare qu'on ait à constamment regarder les fichiers de logs (seulement au début peut être lors de la configuration initiale, et encore). Donc pour les gain que tu gagneras, et l'utilisation que tu en feras, ce n'est pas vraiment rentable. Mieux vaut laisser Arch gérer ça tout seul comme un grand.
Pour la partition /data, c'est normal qu'il n'y ait pas d'explication, y'a rien de bien sorcier. Imagine que c'est une clé USB connectée 24/7. Voilà, tu as ta partition partagée. Il te suffit de faire un peu d'espace sur ton disque. Et s'il y a un problème de droit, de toute façon c'est à l'utilisateur de demander à l'administrateur de lui fournir lesdits droits. C'est son rôle : il administre les droits et veille au bon fonctionnement de son système et sa sécurité. Mais très sincèrement, passez à GitHub si c'est vraiment pour faire du collaboratif. En plus, vous aurez l'avantage d'avoir des logs de ce que vous avez fait et il n'y a pas mieux pour travailler en collaboratif. Et si vous devez travailler en déplacement sur une autre machine -> git clone git add git commit git push. C'est tout simplement magique.
Pour le swap, tu dis que tu n'utilises pas l'hibernation. Mais au vu de la taille de ton disque, mieux vaut en prévoir un pour l'hibernation (donc de taille doublée par rapport à la RAM). Tu l'utiliseras sûrement un jour (même si ce n'est qu'une fois en 1 an) pour une raison X ou Y. Et tu seras bien content de pouvoir sauvegarder ton travail à ce moment là. Ne serait-ce même lorsque tu l'activeras par erreur. Et puis 16 Go sur 1To c'est vraiment pas ce qu'il y a de pire à faire.
Sur 1 TB ? Tu parles donc du laptop, or j'ai prévu d'avoir l'hibernation active dessus, d'où un swap de 8 GB (parce que j'ai que 4 GB de RAM). C'est sur le fixe que j'ai prévu de pas en mettre, mais bon si tu préconise de conserver cette possibilité, je vais voir. De toutes façons le fixe va être pas mal galère à schématiser lui aussi avec ses 4 disques physiquement distincts...
AminNairi a écrit:
La partition var ne sert véritablement qu'à écrire des données variables pour les programmes. C'est souvent utilisé pour les fichiers de logs. Mais pas souvent utilisé par l'utilisateur ou même l'administrateur. Et puis avec Arch, il est rare qu'on ait à constamment regarder les fichiers de logs (seulement au début peut être lors de la configuration initiale, et encore). Donc pour les gain que tu gagneras, et l'utilisation que tu en feras, ce n'est pas vraiment rentable. Mieux vaut laisser Arch gérer ça tout seul comme un grand.
Même quand on utilise des outils de développement local web tels que Apache et PHP qui génèrent et entretiennent des logs à foison ? Ceux de PHP j'ai tout le temps le nez dedans pour le debug, justement...
AminNairi a écrit:
Pour la partition /data, c'est normal qu'il n'y ait pas d'explication, y'a rien de bien sorcier. Imagine que c'est une clé USB connectée 24/7. Voilà, tu as ta partition partagée. Il te suffit de faire un peu d'espace sur ton disque. Et s'il y a un problème de droit, de toute façon c'est à l'utilisateur de demander à l'administrateur de lui fournir lesdits droits. C'est son rôle : il administre les droits et veille au bon fonctionnement de son système et sa sécurité. Mais très sincèrement, passez à GitHub si c'est vraiment pour faire du collaboratif. En plus, vous aurez l'avantage d'avoir des logs de ce que vous avez fait et il n'y a pas mieux pour travailler en collaboratif. Et si vous devez travailler en déplacement sur une autre machine -> git clone git add git commit git push. C'est tout simplement magique.
Pour le travail collaboratif, on utilise déjà GIT (GitHub n'est qu'un site de publication GIT parmi d'autres, hein ? Et en l'occurrence pas le nôtre ). Le problème ici ce n'est pas le travail collaboratif, mais l'utilisation de même environnements par plusieurs utilisateur DE LA MÊME MACHINE, certains n'étant par ailleurs pas humains. Par exemple, un projet web doit pouvoir avoir ses sources accessible et modifiables par tous les utilisateurs humain, tout en étant utilisé par Apache comme espace web local. Si je mettais ça dans le /home, ce serait foireux. Un autre exemple casse-tête est le partage d'une installation WINE, pas envie d'installer la même application Windows 36 fois...
Edit : pour ce matin ce que j'ai tenté (de nouveau) c'est de chgrp le point de montage et son sous-dossier lost+found/, en utilisant le groupe "users" déjà présent. J'ai également chmod le tout notamment pour les droits des membres du groupe. J'imagine que si j'ajoute certains utilisateurs système à ce groupe selon les besoins (je pense à Apache notamment), ça devrait marcher.
- Edité par Darth Killer 17 juillet 2016 à 9:00:48
À priori, toutes les applications WINE s'installe sous .wine ou dans le dossier PlayOnLinux qui sera à la racine du dossier utilisateur. Donc à voir si tu peux peut être changer le dosssier de destination puisque tu peux reprendre un logiciel installé par WINE sur plusieurs machine (donc ici, plusieurs utilisateurs) différent(e)s qui disposent de WINE. Et comme vous aurez à priori la même configuration wine (à moins que ça ne se fasse au niveau de l'utilisateur aussi ?), vous ne devriez pas avoir de problèmes.
Et puis, avec 200Go de root, même pour un serveur web ou mail, c'est relativement énorme (après je ne sais pas quelle activité vous faites en commun, mais quand même !). Donc je serais toi, je ne me préocuperai pas des logs. Ou au pire, si vraiment les logs sont indispensables, tu te fais un cron qui ira faire un rsync sur un serveur cloud ou autre puisque c'est si important et que tu ne veux pas risquer d'en perdre.
À priori, toutes les applications WINE s'installe sous .wine ou dans le dossier PlayOnLinux qui sera à la racine du dossier utilisateur. Donc à voir si tu peux peut être changer le dosssier de destination puisque tu peux reprendre un logiciel installé par WINE sur plusieurs machine (donc ici, plusieurs utilisateurs) différent(e)s qui disposent de WINE. Et comme vous aurez à priori la même configuration wine (à moins que ça ne se fasse au niveau de l'utilisateur aussi ?), vous ne devriez pas avoir de problèmes.
Justement, WINE lui-même avait gueulé pour droits quand j'avais essayé, mais je ne sais pas si le cas précis de WINE sera solvable si facilement car il avait l'air de vérifier le propriétaire du dossier .wine (même avec lien symbolique), pas juste les autorisations.
AminNairi a écrit:
Et puis, avec 200Go de root, même pour un serveur web ou mail, c'est relativement énorme (après je ne sais pas quelle activité vous faites en commun, mais quand même !). Donc je serais toi, je ne me préocuperai pas des logs. Ou au pire, si vraiment les logs sont indispensables, tu te fais un cron qui ira faire un rsync sur un serveur cloud ou autre puisque c'est si important et que tu ne veux pas risquer d'en perdre.
200 GB de root c'est le fixe ça, à affiner. Mais bon dans l'idée c'est plus du dev local + applications qui tournent autour, +/- lourdes (mon fixe ne faisant par ailleurs pas que ça, contrairement au portable qui est vraiment à orienter activité pro). La particularité du laptop étant une possibilité d'avoir besoin de le passer à un collègue avec son propre compte mais bossant sur les mêmes fichiers et utilisant le même serveur web local, d'où le triturage.
Actuellement j'ai mon laptop qui tourne sous Manjaro avec les partitions suivantes :
sda1 : /boot ext2 476.84 MB
sda2 : swap 7.63 GB
sda3 : /root ext4 95.37 GB
sda5 : /var ReiserFS 47.68 GB
sda6 : /home ext4 429.15 GB
sda7 : /data ext4 351.21 GB
non-alloué : 2.49 MB (WTF ?)
Les chiffres sont un poil bizarres et plus petits que quand j'ai défini les partitions, je ne sais pas pourquoi. La taille globale du disque sda aussi a diminué (931.51 GB). Valeurs lues dans GParted à l'intérieur du linux déjà en place
Toutes ces partitions sont dans le fstab, et comme je disais j'ai chgrp et chmod /data/ et /data/lost+found/
- Edité par Darth Killer 17 juillet 2016 à 9:55:00
Et tu n'as jamais exploré la possibilité d'acheter plutôt un bon gros serveur local des familles avec archlinux dessus. Ensuite, sur les postes clients, tu n'as qu'à configurer des liens x11vnc avec la distribution que tu veux (même du windows, tu peux l'utiliser avec putty). Au moins comme ça, tout le monde travail sur le même serveur, serveur qui va servir (whoa je m'étonne de jours en jours) les applications, les documents, etc...
Tu n'aura qu'à gérer depuis le serveur les instances utilisateurs, les dossiers, les applications, etc... Tu peux même leur proposer un bureau différent en fonction de leur envies et créer d'autrese instance VNC.
L'avantage, c'est que les utilisateurs n'auront rien du tout sur leur portable de dev. Simplement de quoi appeler le vnc. Comme je te l'ai dit, même Windows suffit pour ce genre d'utilisation. Le seul souci, c'est que si vous avez besoin de son, ça va être galère à configurer (c'est une horreur pulseaudio + vnc).
Et si tu veux leur proposer la possibilité de collaborer à distance, ssh -X.
Et tu n'as jamais exploré la possibilité d'acheter plutôt un bon gros serveur local des familles avec archlinux dessus.
Tu payes pour nos bureaux ? Parce qu'on en a pas encore... Sans quoi j'aurais mis en place un serveur de dev (probablement un Banana Pi, largement suffisant à moins de devoir faire des tests de robustesse et de charge, et encore...).
Anecdote, il s'agit d'ordinateurs Windows à l'origine, je n'avais pas prévu de claquer la porte à Microsoft avant quelques années au moins.
Donc. On a bien chacun nos ordi pour dev (ou autre), d'où Git pour le collaboratif. Si je cherche à permettre plusieurs utilisateurs sur le mien, c'est en anticipation de devoir potentiellement utiliser ce laptop avec plusieurs personne (par exemple le prêter au stagiaire pendant que je continue à bosser depuis mon fixe).
Déjà je n'ai pas compris c'est pour un serveur ou un desktop ?
Ya pas de serveur. C'est pour un laptop et un desktop. Je fais le laptop en premier.
millman a écrit:
Je ne vais pas l’intérêt de /data un fichier dans /home ne suffit pas ?
Non, je ne crois pas, en raison du cas de figure d'une utilisation par plusieurs utilisateurs humains sur la machine. Ce scénario ne concerne que le laptop, mais quand même. Cette partition /data doit me servir d'espace partagé entre les utilisateurs.
Je ne vais pas l’intérêt de /data un fichier dans /home ne suffit pas ?
Non, je ne crois pas, en raison du cas de figure d'une utilisation par plusieurs utilisateurs humains sur la machine. Ce scénario ne concerne que le laptop, mais quand même. Cette partition /data doit me servir d'espace partagé entre les utilisateurs.
Je ne comprend toujours pas l’intérêt d'avoir une partition dédiée pour cela.
Mais après réflexion une partition dédiée monté avec les ACL d'activé utilisé comme zone d'échange entre utilisateurs peut être utile pour s'assurer que tous les utilisateurs ont toujours tous les droits dans cette partition et les conservent dans tous les cas (ce qui est impossible avec seulement les droits Unix).
Bon pour le laptop j'ai finalement lâché l'idée de le rendre partageable du coup, réinstallé de zéro avec un schéma de partitions plus simple :
500 MB : /boot (ext2)
8 GB : swap
200 GB : / (ext4)
le reste (total du HDD : 1 TB) : /home (ext4)
Toujours Manjaro, bien sûr. Du coup je vais voir pendant l'install software pour les autres tricks en cours de route. A moins que vous n'ayiez quelque chose à ajouter ou préciser ?
Je vais revenir pour le desktop quand je l'attaquerai.
Edit :
Et si je réduis mes partitions de façon à ce que ça tienne plus tard sur mon SSD 250 GB issu du desktop ?
- Edité par Darth Killer 30 juillet 2016 à 12:36:33
Bon, j'ai mon laptop fini aux 3/4, il est temps de se pencher sur le desktop.
La première interrogation : ai-je vraiment besoin de tous ces disques durs maintenant que je switch full linux ? Peut-être que je peux en récupérer, notamment récupérer un SSD pour mettre la config de mon laptop dessus.
Edit : après discussion sur Skype avec mon poto avec qui je partage aussi mes questions, je pense enprunter la voie suivante :
le SSD 120 GB reste et abritera les partitions /boot et /
le HDD 750 GB reste également et abritera le swap, la partition /var et la partition /home
le SSD 240 GB s'en va, et une fois que le desktop marche bien ce SSD sera utilisé pour remplacer le HDD 1TB actuellement dans le laptop (disque dur unique)
le HDD 250 GB (vieillissant) reste dans le boîtier mais n'est branché à rien, ceci permet de le garder à l'abri en attendant d'avoir un usage pour lui. Son rôle sera donc "dans la réserve".
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
Zeste de Savoir | Kali Linux n'est pas une distribution pour débuter ni pour être utilisée tous les jours | Pour choisir une distribution Linux
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?