Forum Linux.debian/ubuntu Petits conseils d'installation

Posté par  . Licence CC By‑SA.
Étiquettes :
1
19
août
2016

Bonjour linuxiennes et linuxiens.

Ça fait un moment que je vous lis mais je ne m'étais jamais inscrit. C'est désormais chose faite pour vous demander quelques conseils.

Je viens de craquer pour un ordinateur Clevo avec un SSD de 128Go, 8Go de RAM et 1To de DD. Du coup, je viens vous demander quelques conseils pour installer Ubuntu (oui, je sais, Ubuntu a mauvaise presse mais je kiffe Unity, sisi) ayant plutôt l'habitude des disques traditionnels. J'ai essayé de me renseigner rapidement ici et là mais certaines choses me paraissent assez floues.

J'imagine que le mieux est d'installer / sur le SSD et /home sur le DD. Certains sites recommandent d'installer /tmp en RAM pour éviter les multiples écritures sur le SSD, c'est encore valable ? Ces sites recommandent en général /var/log en RAM aussi mais là ça me semble vraiment plus qu'étrange. Vous en pensez quoi ?

En faisant quelques recherches, j'ai vu que certains conseillent aussi Btrfs comme système de fichier (sur le site qui date, ils disent que c'est encore en beta, mais ça a l'air d'être stable désormais). Est-ce que ça vaut vraiment le coup pour un mec qui a une utilisation relativement basique ?

Merci d'avance :)

  • # Commentaire supprimé

    Posté par  . Évalué à 1. Dernière modification le 19 août 2016 à 17:51.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Concetées

      Posté par  . Évalué à 1.

      Je suis pas le seul à trouver ça idiot de mettre /tmp en tmpfs alors ? La partition contient jamais plus de 200 Mo chez moi, je vois pas ce que ça peut faire à un SSD. Pourtant tous les "guides" conseillent de faire ça.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Concetées

          Posté par  (Mastodon) . Évalué à 5.

          Mouais… moi je le fais même sur mon ordi fixe (qui croule sous l'espace disque), jamais eu de soucis. Et si jamais une appli un jours fait des misères… bin on n'utilise plus tmpfs !

          Bref, autant le mettre, et l'enlever uniquement si besoin.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Concetées

      Posté par  . Évalué à 6. Dernière modification le 19 août 2016 à 19:44.

      Je ne suis pas d’accord.

      Autant /var/log c’est complètement inepte* autant /tmp c’est une bonne idée si comme moi on a déjà du mal à utiliser les 8GB de RAM disponibles…

      Il doit y avoir des applications qui nécessitent d’avoir un espace important pour /tmp mais là comme ça j’en ai pas qui viennent à l’esprit… l’edition vidéo peut-être…

      Ma distribution utilise des tmpfs pour /var/run et /var/lock (entre autres) et ça me semble être le bon sens même. Dans je dirais 90% des cas c’est bien de mettre /tmp dans la RAM, il est en plus de ce fait vidé à chaque boot comme la norme POSIX le recommande !

      * il y a sûrement des cas anecdotiques où c’est intéressant de faire ça cela dit.

      • [^] # Re: Concetées

        Posté par  . Évalué à 3.

        Effectivement, tmpfs c'est pas seulement pour l'usure SSD, c'est aussi pour la vitesse. Le dossier /tmp n'a que des fichiers qu'on peut perdre. K3b y mets les iso temporaires si on lui demande, et ça va bien plus vite avec un tmpfs.

        Pour ce qui est de /var/log, c'est un choix d'accepter de perdre tous les logs à chaque extinction. Je l'ai fait sur un vieux eeepc dont les disques SSD sont ultra lents, notamment en écriture (5MB/s!)

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Concetées

        Posté par  . Évalué à 2.

        Effectivement, la majorité des applications aurait peut-être du mal à remplir 8G de /tmp, mais ces 8Go représente aussi ta RAM. Du coup, si les applis qui tournent sont un peu gourmandes en RAM, tu n'as pas forcément autant d'espace dispo que ça pour ton /tmp. Tu n'es pas non plus à l'abri d'une appli qui déconne et qui blinde /tmp.

        Par exemple, sur ma machine, il y a quelques années, en sortant d'une mise en sommeil, il arrivait que mon gestionnaire de fenêtre se mette à pondre des lignes de log en continu dans un fichier dans /tmp, jusqu'à saturation de la partition.

        Dans l'absolu, à moins d'auditer dans le moindre détail l'intégralité des trucs qui tournent sur ta bécane, tu ne pourras jamais garantir à 100% que ton /tmp n'épuisera pas ta réserve de RAM. Du coup, il faut regarder ce qui se passe dans le pire des cas. Si tmp est sur le FS, tu blindes ton FS. A priori, c'est pas trop grave. Tu perds des logs, il y a p-e des applis qui se plantent un peu, mais le système d'exploitation continue à fonctionner. Par contre, si tu épuises ta RAM, si tu as du swap, ça va commencer à swapper (un bon coup dans les dents des performances), et à épuisement de RAM+swap, il y a des risques importants que le système crash.

        Sur une machine perso, si tu as beaucoup de RAM et que tu veux réduire l'utilisation du SSD, monter /tmp en RAM peut-être une bonne idée. Si ça sature, un reboot et c'est réglé. Sur un serveur, il vaut probablement mieux monter /tmp sur un FS dédié.

    • [^] # Re: Concetées

      Posté par  . Évalué à 1.

      Merci pour tous les retours, ça confirme certains points !

      J'ai aussi vu que certains n'utilisent plus de swap ou le mette sur le DD plutôt que sur le SSD : j'imagine que l'utilisation de la swap est assez marginale quand on a autant de RAM…

      Bon plus qu'à attendre la livraison maintenant.

  • # Avis perso.

    Posté par  . Évalué à 2.

    J'utiliserais le SSD uniquement pour Linux (/ et /home) et le DD pour du stockage. Je trouve ça plus pratique…

    Sinon, les SSD modernes n'ont pas besoin de beaucoup de réglages. Tu pourras t'assurer que les partitions sont alignées (simple), désactiver un truc ou deux (dans le fstab), mais franchement, ne t'alarme pas pour la durée de vie de ton SSD, ce n'est pas lui qui lâchera en premier. :p

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.