Journal idée la con: un /tmp virtuel

Posté par  .
Étiquettes : aucune
-8
6
août
2009
Confronté à un léger problème d'espace disque sur la partition /tmp, il me vient une idée à la con:
de même que je peux me rajouter du swap à la volée, et le défaire sitôt que je n'en ai plus besoin, pourquoi ne pourrait-on pas faire la même chose avec /tmp ?

J'explique la chose:
Il s'agit d'un serveur LTSP [Linux Terminal Server project http://www.ltsp.org], avec du LVM partout et pas mal de partitions. Il tourne. Une utilisatrice a besoin de graver un gros DVD. Ça ne leur arrive jamais, du coup /tmp n'a pas été dimensionné pour ça.

On peut difficilement prendre le temps de faire un telinit 1, démonter les partitions, les réduire (après un fsck), prendre des extents, les balancer sur /tmp, agrandir la partition (après un fsck) et repartir en init 2. Sans compter les sueurs froides.

Bon, je me débrouille. Mon utilisatrice perd seulement 10 minutes, qu'elle regagne lorsque je lui montre comment bien utiliser k3b.

Mais ?
je ne suis pas censé être dans les locaux, ni disponible pour ce genre de trucs.

Donc j'imagine une solution à la con:
1. On est pas du tout dans le cas des besoins d'un programme démon, mais dans ceux d'une utilisatrice ayant occasionnellement et pour peu de temps besoin de plus d'espace disque.
2. L'utilisatrice ne peut pas apprendre à reconfigurer K3B pour changer de dossier /tmp. Faut pas rêver.
3. Si j'avais un /tmp, en partie réel (partition dédiée), en partie virtuel? Cette partie virtuel prendrait des bouts d'espace libre là ou y'en a (avec un pourcentage maximum). Elle rendrait de l'espace sitôt la fermeture de l'application.

Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitionner!
Mais bien sûr.
Et la fragmentation alors ?

Vous allez dire, c'est con^X^X c'est pas futé, savatoufragmentaï!
Mais bien sûr.
Bien souvent les utilisateurs font une seule chose à la fois

Vous allez dire, c'est con^X^X c'est pas futé, savanoufère un démon de plus.
Mais bien sûr.
Ça bouffe pas un démon. Et puis ma tranquillité vaut bien ça.

  • # La fragmentation, on s'en fou !

    Posté par  . Évalué à 8.

    C'est des fichiers temporaire.

    • [^] # Re: La fragmentation, on s'en fou !

      Posté par  . Évalué à 1.

      D'autant plus que pour ce qui est des systèmes de fichiers modernes (à partir de ext2 quoi, NTFS non compris bizarrement) plus on les utilise moins ils fragmentent !!

      ( http://www.dicosmo.org/HoldUp/HoldUpPlanetaire.pdf page 45 )

      • [^] # Re: La fragmentation, on s'en fou !

        Posté par  . Évalué à 6.

        T'as pas des références plus récentes?
        Parce qu'on fragmente au contraire, surtout avec l'utilisation actuelle (gros fichiers dans les emails, téléchargement de sons, d'isos, de programmes et de vidéos à tout va, insertion d'images en haute def un peu partout, etc.).

        C'est d'ailleurs pour ça qu'on met des extents dans EXT4 et BTRFS (l'allocation par extent permet la pré-allocation d'une zone contigüe pour un fichier, pour minimiser la fragmentation).

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: La fragmentation, on s'en fou !

      Posté par  . Évalué à 1.

      Evidemment qu'on se fout de la fragmentation de /tmp. Le problème c'est la fragmentation que peut provoquer /tmp s'il n'est pas sur sa partition dédiée:
      C'est un serveur LTSP. Il y a donc plusieurs personnes travaillant simultanément dessus. Chacune reçoit 150-300 emails par demi-journée, avec des grosses pièces jointes et chacune crée une trentaine de documents par jour, sans compter les incessantes modifications des docs existants. S'y ajoutent les gravures de CD. Enfin le cache des navigateurs est sur /tmp.
      Du coup /tmp se remplit vite, notamment à cause des pièces jointes des emails.
      Et donc, si ça n'était pas partitionné, les fichiers temporaires provoqueraient la fragmentation du reste.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitionner

    Posté par  (site web personnel) . Évalué à 10.

    ... Oui, je vais te dire ça.

    Un répertoire qui prends de l'espace disque sur une partition au fur et à mesure qu'il se remplit, ça existe déjà, il suffit de mettre ledit répertoire sur une partition, c'est tout.

    Si tu veux que /tmp/ prenne l'espace disque sur /dev/hda1, bah, faut mettre /tmp sur la partition /dev/hda1.

    • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

      Posté par  (site web personnel) . Évalué à 0.

      ou utiliser /var/tmp/
      y'a sûrement plein de place dans /var ... non ?

    • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

      Posté par  . Évalué à 1.

      Euh, c'est déjà le cas: tout est en LVM, /tmp a sa partition dédiée, mais c'est vrai j'ai oublié de le préciser. Le hic c'est que très occasionnellement elle est trop petite. Et on ne peut pas changer les disques.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

        Posté par  (site web personnel) . Évalué à 2.

        Ben, agrandis-la… Où est le problème ?

        • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

          Posté par  . Évalué à 2.

          Le problème c'est l'utilisatrice: elle veut graver tout de suite.

          Comme je l'ai dit:
          On peut difficilement prendre le temps de faire un telinit 1, démonter les partitions, les réduire (après un fsck), prendre des extents, les balancer sur /tmp, agrandir la partition (après un fsck) et repartir en init 2. Sans compter les sueurs froides.

          Mon utilisatrice elle veut graver tout de suite.
          Et puis je ne suis pas censé être sur place.

          PS: je viens de comprendre qu'on est pas vendredi, ça aurais été plus rigolo si j'avais posté demain (quel superbe emploi du passé pour parler du futur!).

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

            Posté par  . Évalué à 1.

            Euh ... c'est pas l'un des buts de LVM que de redimensionner à chaud ?

            • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

              Posté par  . Évalué à 3.

              LVM on met les bon vieux filesystems d'antan dessus. Après, si tu as un système de fichiers redimensionnable à chaud, tout est permis !

            • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

              Posté par  . Évalué à 2.

              Oui mais pour redimensionner à chaud avec LVM (je suppose que tu veux dire agrandir), il faut avoir des Physical Extents disponibles. On va dire que je n'en ai pas. Il faut donc d'abod réduire quelque part, ce qui ne se fait pas à chaud.

              Et puis je le redis::
              l'utilisateur n'est pas censé attendre ni avoir besoin de moi.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

                Posté par  (site web personnel) . Évalué à 3.

                l'utilisateur n'est pas censé attendre ni avoir besoin de moi

                Et bien tu prévoies assez dès le début, ou tu ne partitionne pas. Si ton but c'est que, momentanément, un répertoire donné de la hiérarchie (/tmp, ici) puisse prendre plein de place, la solution, c'est clairement de ne pas partitionner.

                • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

                  Posté par  . Évalué à 2.

                  Ça n'a pas été possible de prévoir assez: la taille des documents produits a fait un bond gigantesque - merci les appareils numériques, la vidéo, le son - un bond plus grand que le budget alloué par le gentil gouvernement.

                  Il est clair que ne pas partitionner est la solution la plus simple.

                  C'est égal, je veux le beurre, la tartine et la confiture: je veux pouvoir partitionner et voir mon /tmp faire du yoyo tout seul. Mais bon ça peut attendre quelques années.

                  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                  • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

                    Posté par  . Évalué à 3.

                    solution proposé sur un serveur de stockage qui gérait pas les quota (non c'est pas un linux maisçca marche aussi dans ton cas)
                    tu alloues 80% de l'espace disque, et tu garde 20% (chiffre pouvant varier suivant l'utilisation)
                    Quand tu dois utiliser les 20% de façon continue (cad autre chose que juste rajouter ton /tmp puis le virer après)
                    tu envoies un mail à ton responsable "coucou on a plus de disque. Ca serait bien d'en rajouter un".

                    Bon je sais faut demander longtemps et souvent (nous on a disque qui est mort sur un san, la commande est parti aux achat, puis elle est revenue "ouais ... pas assez cher, on atteint pas le minimum de commande" ... grrr c'est pressé on a dis
                    donc redemander un devis, refaire les achats... heureusement que c'est pas moi qui m'en occupe XD
                    ).

      • [^] # Re: Vous allez dire, c'est con^X^X c'est pas futé, yaka ne pas partitio

        Posté par  . Évalué à 3.

        En fait il t'a suggéré de ne pas en faire une partition dédiée.
        Si tu veux que ça puisse utiliser de l'espace d'une autre partition, alors ça fait partie de l'autre partition.

  • # bof le mien est en tmpfs

    Posté par  . Évalué à 10.

    donc en ram :D, si j'ai besoin de plus d'espace, suffit de rajouter du swap :P

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: bof le mien est en tmpfs

      Posté par  . Évalué à 1.

      Spa mal, mais si c'est pour avoir toutes ses applis en swap parce que ton /tmp prend toute la mémoire vive, c'est un peu naze, non ?

      • [^] # Re: bof le mien est en tmpfs

        Posté par  . Évalué à 2.

        en même temps j'ai jamais considéré tmp pour les gros fichiers; et quand je grave un dvd, je le fais à la volée (note bien qu'un jour j'ai tenté sur ma partition d'échange l'image se bloquait constamment a 4096 octets... j'ai mis du temps à me rappeler la limite du fat32... Depuis je fait à la volée, et j'ai de toutes façons suffisamment d'espace sur mes patoches de travail pour le faire. )

        et puis il a dit que les personnes faisaient tourner généralement qu'une appli, alors ça devrait pas être gênant, suffit juste de mettre une alarme sur la fin/les alertes, le volume bien fort, et faire un tour à la machine à café. (Je connais des gens qui avaient songé à envoyer un mail sur un compte qui l'envoyait en sms pour être prévenu de la fin d'une tâche)

        Une autre solution serait une clé usb de 8Go, et la partitionner en ext3, maintenant ça se monte tout seul :D

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: bof le mien est en tmpfs

          Posté par  . Évalué à 2.

          et puis il a dit que les personnes faisaient tourner généralement qu'une appli

          multiplié par le nombre de personnes (elles sont toutes sur le même serveur qui fait données & application).

          suffit juste de mettre une alarme sur la fin/les alertes, le volume bien fort, et faire un tour à la machine à café

          Tu rêves. Le directeur repasserait à Windows tout de suite. Bref, dans la vraie vie d'une fourmillière c'est impossible.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: bof le mien est en tmpfs

        Posté par  . Évalué à 3.

        C'est pas ton problème, c'est celui de l'OS, et il fera ce qu'il faut :
        si un processus utilise massivement /tmp, alors le processus et /tmp seront dans la RAM, au détriment des autres processus (ceux qui ne font rien donc on s'en fout un peu) ; dans la situation inverse /tmp sera majoritairement swapé sur le disque pour accéder plus rapidement aux processus.
        Maintenant avoir plus de données (processus+/tmp) que de quantité de RAM, et swaper sur disque n'est jamais bon, et aura toujours un impacte coté perf et reactivité...

        • [^] # Re: bof le mien est en tmpfs

          Posté par  . Évalué à 2.

          C'est pas bête, mais le swap n'est pas créé au vol. C'est une partition ou des fichiers définis avant... Mais le swap ne me servant que très rarement il y a toujours de la place. Par sécurité il est plutôt gros. En 3 ans il ne s'est rempli que 2 fois.

          Maintenant avoir plus de données (processus+/tmp) que de quantité de RAM

          Dans leur cas, ça n'arrive que très très très rarement (les applis utilisent aussi la RAM du client X). C'est une solution acceptable. Et donc intéressante!

          Par contre ça va fragmenter la Ram. Mais ça n'est pas très grave, la Ram est rapide.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: bof le mien est en tmpfs

            Posté par  . Évalué à 1.

            Par contre ça va fragmenter la Ram. Mais ça n'est pas très grave, la Ram est rapide.

            Non, ça t'en sait rien, ça dépend de ce qui est fait dans le noyau. Je me garderais bien de faire le moindre pronostique sur la fragmentation de la RAM, et sur l'impacte sur les perfs : on peut trés bien avoir une RAM fragmentée sans impacte sur les temps d'accès, ça dépend de la granularité de la fragmentation et des modes d'accès aux blocs de données, bref faut se plonger dans le code du noyau et dans les docs techniques de fonctionnements des RAMs pour espérer deviner le comportement du système.

            Vu la complexité des phénomènes mis en oeuvre, et la multiplicité des configurations possibles, comme souvent en informatique, il faut bencher et ne pas se fier à son intuition...

      • [^] # Re: bof le mien est en tmpfs

        Posté par  . Évalué à 1.

        Sauf que tu peux définir la taille maximum d'un tmpfs (par défaut, la moitié de la RAM)

  • # $TMPDIR

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Et il ne suffirait pas de définir (et d'exporter) $TMPDIR vers un répertoire où il y a de la place ?

    • [^] # Re: $TMPDIR

      Posté par  . Évalué à 2.

      Dans K3B, à priori c'est quelque chose comme Settings -> Configure K3B -> Default Temporary Directory.

      Ayant comme d'autres personnes un /tmp en tmpfs (ce qui est pratique pour mettre beaucoup de choses, que ça soit les fichiers classiques de /tmp ou des fichiers téléchargés "pour voir". En plus, c'est très rapide, le filesystem ne se fragmente pas au fil de l'utilisation, ne se corrompt pas, et est automatiquement nettoyé à l'extinction...).

      Je n'ai pas vraiment la place de copier trop de choses dedans, mais ça me pose aucun problème puisque les logiciels qui consomment vraiment beaucoup d'espace disque sont prévus pour être configurables de ce côté là.

      • [^] # Re: $TMPDIR

        Posté par  . Évalué à 2.

        (je répond aux deux)

        Comme je l'ai dit, on ne peux pas demander aux utilisateurs d'intervenir.
        Je préfère laisser le $TMPDIR des logiciels comme K3B sur la partition /tmp, car en temps normal ça ne pose pas de problème.

        est automatiquement nettoyé à l'extinction
        Une partition /tmp c'est au démarrage. Mais c'est un serveur, on ne l'éteint (presque) jamais.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: $TMPDIR

          Posté par  . Évalué à 3.

          Pourquoi ne pas distribuer des fichiers de conf par défaut pour tout le monde si on ne veut pas le laisser faire par les utilisateurs?

          • [^] # Re: $TMPDIR

            Posté par  . Évalué à 2.

            Il y a déjà des fichiers de conf par défaut, qui vont très bien. Mais il y a des situations ponctuelles où ils ne collent pas. Et dans ces situations, c'est pas qu'on ne veut pas, c'est qu'on ne peut pas laisser les utilisateurs se débrouiller. Soit parce qu'ils ne savent pas - et ne veulent pas savoir - soit parce qu'il ne veulent même pas le faire.

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: $TMPDIR

              Posté par  (site web personnel) . Évalué à 5.

              Mais il y a des situations ponctuelles où ils ne collent pas.

              Oui mais tu te fais chier pour rien... si la conf lors de la situation ponctuelle qui est en gros que le /tmp est sous-dimensionné pointe vers un endroit où il y a de la place... ben en tant normal où tu as pas besoin de toute cette place, ça convient aussi... alors une seul conf et pas dans le /tmp et basta problème réglé, tu peux boire un café !

              • [^] # Re: $TMPDIR

                Posté par  . Évalué à 2.

                c'est vrai qu'un petit export TMPDIR=$HOME/.tmp dans le .profile ferait parfaitement l'affaire.

    • [^] # Re: $TMPDIR

      Posté par  . Évalué à 4.

      Qui plus est, si les utilisateurs ne sont pas spécialement intimes entre eux, je trouve que c'est leur faire violence que de leur donner le même $TMPDIR.

      • [^] # Re: $TMPDIR

        Posté par  . Évalué à 4.

        Y'a

        [I] sys-auth/pam_mktemp
        Description: Create per-user private temporary directories during login

        Par défaut ça met $TMPDIR sur $TMPDIR/.private/ mais ça peut se configurer.

        D'ailleurs depuis que je l'utilise j'ai remarqué que comme pour les variables XDG certaines applis ne prennent pas en compte le TMPDIR :/

  • # Pourquoi faire simple…

    Posté par  . Évalué à 10.

    Et on pourrait aussi créer une machine virtuelle qui résiderait dans /tmp mais qui irait chercher son espace disque sur des nfs via un protocole p2p à définir. Et on aurait un immense /tmp partagé mondialement et qui serait vidé via un cron chaque fois que Sarkozy dit une connerie.

    • [^] # Re: Pourquoi faire simple…

      Posté par  . Évalué à 2.

      C'est un peu dans cet esprit que j'avançais cette idée à la con.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # JBOD

    Posté par  . Évalué à 3.

    Moi j'aurais bien vu une gestion de /tmp a la facon swapon/swapoff, cad tmpon et tmpoff qui agissent en gros sur une sorte de JBOD

  • # K3B

    Posté par  (site web personnel) . Évalué à 0.

    C'est K3B qui craint. Un bon logiciel de gravure génère l'image à graver en flux, et la passe, toujours en flux, au graveur. Concrètement, ça donne mkisofs | wodim.

    • [^] # Re: K3B

      Posté par  (site web personnel) . Évalué à 4.

      Il le fait par défaut...

      • [^] # Re: K3B

        Posté par  (site web personnel) . Évalué à 2.

        Alors pourquoi a-t-il besoin de plein de place dans /tmp ?

        • [^] # Re: K3B

          Posté par  (site web personnel) . Évalué à 2.

          Si tu n'as qu'un seul lecteur/graveur pour copier un DVD tu es obligé de mettre l'image du DVD sur ton disque dur à un moment donné. Par défaut k3b met l'image dans /tmp.

      • [^] # Re: K3B

        Posté par  . Évalué à 2.

        Sur une Debian Lenny, sans avoir modifié K3B, ça n'est pas le cas.
        A moins que ça vienne des installations précédentes (les répertoires utilisateurs ont été importés).

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: K3B

          Posté par  (site web personnel) . Évalué à 2.

          Sur Mandriva, la configuration par défaut (vérifiée en ayant supprimé les fichiers de confs k3b), c'est bien de ne pas utiliser d'image iso temporaire.

    • [^] # Re: K3B

      Posté par  . Évalué à 2.

      Il faut aussi pouvoir recopier un CD/DVD.
      Et puis générer l'image avant permet de la vérifier, non (je dis peut-être une connerie).

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # LVM

    Posté par  . Évalué à 3.

    Perso, je ne vois pas le problème dès que tu utilise LVM. Tu peux dès lors augmenter la taille de ta partition à la volée et la réduire de même et ce sans rien démonter.

    Bien sur, il faut de la place sur le disque dur pour faire cela, mais un petit démon peut très bien allouer de l'espace supplémentaire à une partition à la volée selon l'occupation de celle-ci. Style si espace libre inférieur à 20% => allouer 1Go supplémentaire.

    L'inverse est aussi possible.

    L'espace peut dès lors être distribué automatiquement selon l'utilisation de chaques partitions.

    Et si il n'y plus de place pour /tmp par exemple, on peut créer un PV dans l'espace mémoire, le rajouter dans le VG et donner l'espace au LV /tmp. Personnellement, c'est une chose que je ne ferais pas. Si le PV n'a pas été correctement enlevée, cela peut poser problème à LVM.

    On peut aussi rajouter un disque dur ou une clé pour palier ce problème temporaire de place.

    • [^] # Re: LVM

      Posté par  (site web personnel) . Évalué à 2.

      Niveau fragmentation c'est un peu suicidaire quand même.

      • [^] # Re: LVM

        Posté par  (site web personnel) . Évalué à 3.

        Euh, la fragmentation, la fragmentation… on s'en fout ?

        Aujourd'hui, un disque dur est utilisé en permanence et dans tous les sens, surtout sur un serveur. Alors qu'un système de fichiers ait 1 Go ici, et 2 Go à l'autre bout du disque, franchement… Surtout qu'avec un minimum de mémoire, tout ça fini intensivement caché, donc la fragmentation, honnêtement, je ne m'inquiète pas pour ça.

        • [^] # Re: LVM

          Posté par  (site web personnel) . Évalué à 3.

          Pour avoir déjà souffert de fragmentation pas bien énorme, tu dis n'importe quoi. Sur un système XFS (le seul FS que je sais comment défragmenter correctement), qui était en permanence dans les 90% d'utilisation disque, ça se mettait à ramer sérieusement. J'ai fait un petit xfs_fsr, et la machine est redevenue utilisable ....
          Et j'ai déjà eu d'autres cas du genre. Et maintenant que je suis passé à ext4, après l'installation mon système était extremement réactif, maintenant nettement moins, et je soupçonne fortement la fragmentation, hélas je n'ai trouvé aucun outil pas trop compliqué à utiliser pour défragmenter un ext4 (y a bien e4defrag mais aux dernieres nouvelles faut patcher le noyau)
          Alors c'est pas le même ordre de grandeur de fragmentation ('fin si tu veux redimensionner le /tmp toutes les 30secondes, ça fera même encore pire.)

          • [^] # Re: LVM

            Posté par  . Évalué à 2.

            Il parlait du LVM. La fragmentation du LVM ne sera jamais énorme: les physical extents resteront groupés, mêmes si les groupes seront répartis ici ou là.

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: LVM

              Posté par  (site web personnel) . Évalué à 3.

              S'il veut vraiment avoir un tmp qui s'adapte à l'utilisation, ça sera pareil, et même pire (vu que LVM ne sait pas gérer la fragmentation, que le FS croira être sur un FS contigüe, 'fin un vrai cauchemar quoi de disque dur (et reve de SDD ;))

          • [^] # Re: LVM

            Posté par  . Évalué à 3.

            qui était en permanence dans les 90% d'utilisation disque,
            Euh normal que ca se mette a ramer, les fs sont pas prévu pour fonctionner aux limites des disques dur.
            Il leur faut un peu d'espace.

    • [^] # Re: LVM

      Posté par  . Évalué à 2.

      Tu peux dès lors augmenter la taille de ta partition à la volée et la réduire de même et ce sans rien démonter.

      Non c'est faux. Tu peux augmenter sans démonter, mais pour réduire la taille d'un système de fichier, il faut le démonter - en tout cas sous Linux: je crois que ZFS, Hammer et Btrfs permettent de réduire à chaud, mais aucun d'eux n'est dispo.

      un petit démon peut très bien allouer de l'espace supplémentaire à une partition à la volée selon l'occupation de celle-ci. Style si espace libre inférieur à 20% => allouer 1Go supplémentaire.

      un peu comme dans mon idée à la con, quoi... :-)
      reste le problème de le désallouer à la volée.

      On peut aussi rajouter un disque dur ou une clé pour palier ce problème temporaire de place.
      non, l'idée c'est de ne pas intervenir.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # euh, et POSIX ?

    Posté par  . Évalué à 4.

    Il me semble que POSIX prévoit l'utilisation de la variable d'environnement TMPDIR pour ce genre de chose. Et un paquet d'application doivent le gérer.

    Si les applications dont tu (tes utilisateurs) as (ont) besoin respectent ça, il te suffit d'ajouter la définition de TMPDIR dans le $HOME de l'utilisateur dans /etc/profile ou autre.

  • # psychologie

    Posté par  . Évalué à 3.

    C'est plus un problème psychologique que physique

    (...) yaka ne pas partitionner!(...)
    Et la fragmentation alors ?
    (...)
    Vous allez dire, c'est con^X^X c'est pas futé, savatoufragmentaï!(...)les utilisateurs font une seule chose à la fois

    Faudrait que tu te mette d'accord avec toi même
    -si tu te fou de la fragmentation : tu fait un rep /tmp dans une autre partition
    -sinon comme les autres le dise tu peu faire joujou avec lvm ou tmpfs mais bon ca a d'autres desavantages.

    bref moi je m'embêterai pas surtout si c'est pour des utilisateur lambda ca sert a rien de faire un tuné les truc au petit oignons car soit il n'utilisera pas 1% de ta mega config ou alors (comme ici) il va tombé dans le cas foireux qui fais chier!

    • [^] # Re: psychologie

      Posté par  . Évalué à 2.

      bref moi je m'embêterai pas surtout si c'est pour des utilisateur lambda ca sert a rien de faire un tuné les truc au petit oignons car soit il n'utilisera pas 1% de ta mega config ou alors (comme ici) il va tombé dans le cas foireux qui fais chier!

      Ah mais tout à fait. C'est justement pour ne pas me faire chier que je fais un journal: j'attends vos solutions ;-)

      Et curieusement sur Linuxfr un journal assez con suscite des commentaires de qualité. L'inverse est tout aussi vrai: un journal intéressant dégénère en trolls!

      Blague à part, évidemment qu'on ne peut pas tout prévoir, sinon à quoi on servirait? J'apprécie justement les configs toutes simples sur lesquelles un admin de passage peut intervenir sans tout péter.
      Mais j'aime bien imaginer des trucs. Surtout s'il s'agit d'espace temporaire, car ne plus en avoir c'est gênant. Bref, ça m'amuse. Comme dans le célèbre "blues d'un administrateur système":
      Quoi de plus stimulant sinon de savoir que résoudre un problème ne viendra en aucune façon enrichir ce qu’il est convenu d’appeler l’expérience, puisque le même problème nécessitera lorsqu’il se posera à nouveau une solution radicalement différente.
      Cette idée à la con, c'est comme la reconversion d'un Vax en calculette.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # utiliser les shared subtrees (faire un slave mount)

    Posté par  . Évalué à 5.

    - faire un submount là où il y a de la place.
    - ou encore un slave mount:
    A slave mount receives propagation from its master, but any not vice-versa
    le process qui a besoin de place fait
    mount --bind /tmp /home/toto/tmp (par exemple)
    mount --make-slave /home/toto/tmp
    Du point de vue du process /tmp ne change pas mais en réalité il utilise /home/toto/tmp

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: utiliser les shared subtrees (faire un slave mount)

      Posté par  (site web personnel) . Évalué à 2.

      Du point de vue du process /tmp ne change pas

      À moins d'utiliser UnionFS ou AuFS, si, il change, et pas qu'un peu : tout à coup, il devient vide, vu que c'est un montage tout neuf. Plus moyen d'accéder à son ancien contenu.

      • [^] # Re: utiliser les shared subtrees (faire un slave mount)

        Posté par  . Évalué à 4.

        Non, ce n'est pas un montage ordinaire.
        /home/toto/tmp est esclave de /tmp
        /home/toto/tmp "contient" tout ce qui est dans tmp, l'inverse n'étant pas vrai.

        Le man de mount n'est pas très explicite, mais regarde sharedsubtree.txt dans la doc du noyau.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Les subvolumes de btrfs ?

    Posté par  . Évalué à 4.

    Btrfs a des "subvolumes" qui sont des "partitions" qui n'ont pas de taille fixée (enfin, on peut le fixer optionnellement). Ainsi, tu pourrais avoir un subvolume /tmp qui n'est pas limité en taille comme une partition classique. Par contre, je pense que niveau fragmentation, ça ne change pas grand chose par rapport à ne pas faire de sous-volume ...

    Enfin, je ne comprend pas trop ton problème, en fait : tu veux pouvoir faire "gagner de la place à tmp". Va bien falloir la trouver cette place. Tu veux la prendre sur / ? Bah fallait prévoir un /tmp plus gros, et un / moins gros. Ha, mais tu veux aussi un / gros ? Bah réduis ton /tmp. Ha, mais tu veux qu'ils s'équilibrent ? Bah, fait qu'une partition pour /, /tmp s'adaptera automatiquement. Ça ne te va toujours pas ? Tu veux qu'il trouve de l'espace disponible automatiquement ? La génération spontanée d'espace disque, ça te va ? Je t'en fais pour pas cher ...

    • [^] # Re: Les subvolumes de btrfs ?

      Posté par  . Évalué à 2.

      Je suis allé voir du côté de Hammer aussi, je ne pensais pas que Btrfs était aussi avancé.

      En fait mon idée est simple:
      La plupart du temps, en utilisation burautique, on n'a pas besoin d'un très gros /tmp. Très occasionnellement, on peut avoir besoin de beaucoup plus de place.
      L'utilisateur ne doit pas avoir à s'en inquiéter - et de toute façon la plupart ne savent pas comment faire.
      S'il y a de la place sur d'autres partitions, pourquoi ne pas y aller grapiller automagiquement quelques gigas?
      Quelques minutes après on les rend!

      Bien sûr ce n'est pas vital, ce serait plus indiqué pour du swap. C'est seulement pour le confort de l'utilisateur. Mais pour le confort, on a déjà fait un tas de choses pas vraiment indispensables, comme l'auto-montage des CD-ROMS. Alors pourquoi pas?

      Je donne des exemples de cas:
      Ils sont plusieurs à travailler sur un petit serveur. Avec le temps, il est devenu juste et les partitions ne peuvent plus grandir. Et avec l'évolution du numérique ils produisent des documents de plus en plus gros, et le web demande plus de cache, etc. et voilà /tmp qui se remplit beaucoup plus vite. Il arrive alors (c'est arrivé 2 fois) qu'ils reçoivent par email des photos de spectacle en très très haute définition (ça remplirait un DVD). Quand on ouvre les pièces jointes, ça crée une copie dans /tmp. A la 5e photo ça ne s'ouvre plus.

      Ou encore ils doivent graver un DVD. C'est urgent bien sûr. Ça ne leur arrive jamais. Vu la config, /tmp est trop petit.

      Qu'on ne me parle pas d'utilisateur débile, ou qui n'à qu'a faire comme ci ou comme ça. Je parle de confort.
      Qu'on ne parle pas non plus de serveur à changer, de disque à acheter. Il y a plein de petites structures où ça ne se décide pas comme ça.

      Et je n'ose pas penser au cas d'un Blue-Ray. C'est super pour des archives, mais il me faudrait un /tmp de quelle taille ??? Je veux vérifier mon image avant de la graver, pas graver en flux. C'est la procédure pour un archivage de longue durée. Et de toute façon j'en fais 3 copies (master au coffre, copie ailleurs, copie sur site).

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

Suivre le flux des commentaires

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