Journal Stockage de Mail, espace : Maildir/mbox/...

Posté par (page perso) .
14
5
mai
2009
Bonjour,

La quantité de mail à stocker est toujours plus grande. Pour de grandes institutions (>30.000 personnes), l'archivage et la conservation des mails peut devenir très problématique.

Or, si on regarde les 2 principaux sytème de stockage de mailboxes sur les systèmes libres, càd mbox et maildir, on remarque immédiatement qu'il n'y a rien de fait concernant l'optimisation du stockage.

Pourtant, on remarque rapidement que dans le stockage beaucoup de données sont tout simplement dupliquées :
- Chaque fois qu'un mail est envoyé à X personne ce mail est stocké X fois sur le serveur
- Chaque fois que forward avec pièces jointes est fait, tout est dupliqué

Je pense qu'il doit être possible de faire un système de stockage qui enregistrerait une seule fois les données et des liens vers ces données. Un méchanisme à la copy-on-write pourrait être mis en place en cas d'écriture par un utilisateur.

Est-ce que ce type de système existe (dans le libre) ? Je n'ai pas trouvé. Est-ce que vous pensez que cela est une bonne idée ? Je pense personnellement que les besoins en stockage seraient dramatiquement plus bas.
(43 commentaires).

  • # Gmail

    Posté par (page perso) . Évalué à 6.

    Je suppose, mais ce n'est qu'une supposition, que Gmail fonctionne comme cela. Mais ce n'est pas libre !

    • [^] # Re: Gmail

      Posté par (page perso) . Évalué à 5.

      C'est bien ça le problème. Je connais un grand nombre de gens qui forwardent leur mail professionnel vers gmail et autres car la mailbox pro se traine au niveau de 50Mo de stockage ce qui n'est vraiment plus gérable actuellement (Le moindre document fait quelque Mo).

      • [^] # Re: Gmail

        Posté par (page perso) . Évalué à 6.

        Vive la confidentialité... En même temps entre les .doc à 10Mo et les gens qui envoient des images .bmp, y a p'tet un peu d'éducation à faire côté utilisateur pour que les gens utilisent des formats compressés...

        • [^] # Re: Gmail

          Posté par . Évalué à 6.

          y a p'tet un peu d'éducation à faire côté utilisateur pour que les gens utilisent des formats compressés...

          C'est vrai - et d'ailleurs de manière plus générale - mais ça ne fait que repousser le problème.

        • [^] # Re: Gmail

          Posté par . Évalué à 2.

          Mieux encore : éduquer les utilisateurs à faire proprement leurs besoins de gros documents dans des espaces de partage de documents dédiés (GED, Wiki, CMS, ou n'importe quel outil du genre) !

          C'est d'ailleurs une qualité du mal-aimé Lotus Notes : il peut proposer automatiquement de publier les pièces jointes sur Quickplace (l'outil IBM pour le partage de contenus) au lieu de la diffuser directement aux destinataires.

          BeOS le faisait il y a 15 ans !

          • [^] # Re: Gmail

            Posté par (page perso) . Évalué à 2.

            Cela ne résout pas le problème des mails venant de l'extérieur et des mailing list. Les attach ne sont pas la seule source d'occupation de place. 30.000x un mail de 10ko cela donne 300Mo pour un seul mail. Alors que cela pourrait(devrait)-être 30.000x un index de (64bits) + 1x le mail = 250ko.

          • [^] # Re: Gmail

            Posté par . Évalué à 0.

            du coup le problème est la déconnexion et la pérennité des données, tu conserves tes mails, mais hop le wiki il crève et t'as plus que des 404, ou bien ton CMS change et toutes les urls sont fausses...

        • [^] # Re: Gmail

          Posté par . Évalué à 10.

          Avis personnel :
          Le mail n'est pas un système fiable pour la confidentialité !
          Si on envoie un document par mail, il faut si dire que tout le monde peut le lire.
          On peut utilisé un serveur personnel bien sécurisé, on ne sait pas par où le mail va transiter.
          Alors, il n'y a qu'une solution pour concilier mail et confidentialité : le chiffrement.
          Et là, ça peut bien être hébergé chez gmail, ça ne change en rien la confidentialité, vu qu'ils stockent juste un mail indéchiffrable.

          Le problème de gmail, c'est la centralisation, pas la confidentialité.

  • # Gmail anyone ?

    Posté par (page perso) . Évalué à 2.

    Ce que tu décris ainsi que pas mal d'autres astuces est utilisé par gmail pour fournir un maximum de mail avec un minimum de ressources. J'ai pas entendu parlé d'implémentation équivalent dans le libre. Quand tu vois que ThunderBird ne gère toujours pas le format maildir...

    • [^] # Re: Gmail anyone ?

      Posté par (page perso) . Évalué à 6.

      >Quand tu vois que ThunderBird ne gère toujours pas le format maildir...

      Cela n'est pas bien grave. Le but ici est d'avoir un système remote en imap et donc, plus rien en local. Cela doit donc être implémenté au niveau du MTA et du serveur imap.

  • # Hard links & comportement COW

    Posté par (page perso) . Évalué à 2.

    Une recherche rapide montre un début de solution ainsi que des mots-clés intéressants : je pense qu'un script qui recherche les fichiers identiques[1] (lancé par cron par exemple) et les transforme en hard links, couplé à FL-COW[2] qui intercepte les écriture pour casser le hard link, pourrait être un début de solution.

    [1] http://finddup.sourceforge.net/
    [2] http://www.xmailserver.org/flcow.html

    • [^] # Re: Hard links & comportement COW

      Posté par (page perso) . Évalué à 3.

      >je pense qu'un script qui recherche les fichiers identiques[1] (lancé par cron par exemple)

      Le but est de le faire à la source et pas postmortem. Il faut que cela soit fait à la réception du mail.

      • [^] # Re: Hard links & comportement COW

        Posté par . Évalué à 2.

        C'est Peut être faisable via un maildrop/procmail/plugin pour dovecot LDA ou autre mais cela me semble couteux, surtout que cela peut vite devenir un goulot d'étranglement.

        A moins que tu ai des centaines de grosses pieces jointes envoyées chaque jour, je pense que l'idée du cron n'est pas forcément mauvaise.

        • [^] # Re: Hard links & comportement COW

          Posté par (page perso) . Évalué à 2.

          >A moins que tu ai des centaines de grosses pieces jointes envoyées chaque jour, je pense
          >que l'idée du cron n'est pas forcément mauvaise.

          L'idée n'a pas beaucoup de sens s'il n'y a pas beaucoup de mailboxes, donc, oui, il y en a pas mal.

          • [^] # Re: Hard links & comportement COW

            Posté par . Évalué à 3.

            Si tu envisages cela , tu peux même envisager une solution plus drastique:

            Forcer les gens à uploader les pièces jointes sur sur un système de GED externe: typiquement http://documents.boite . Et envoyer des liens. Cela pose d'autres problèmes, mais laisse entrevoir d'autres solutions.

            Problème: il faudra penser à la gestion des droits, et sans doute l'implémenter.

            Solutions:
            - Interdire les grosses pièces jointes et coder un mini plugin pour thunderbird ou le webmail si celui ci est libre (à condition qu'il y ai pas de récalcitrants avec d'autres clients).

            - Enregistrer toute pointe jointe reçu dans cette base et y ajouter une autorisation à la réception du mail (via procmail/......) et remplacer dans le contenu du mail cette pièce jointe par un lien. Cela resolverait aussi le problème évoqué si dessous (format des boites).

            • [^] # Re: Hard links & comportement COW

              Posté par (page perso) . Évalué à 4.

              De mon expérience personnelle, je préférerais une solution 100% transparente, sans impact sur la façon de travailler des gens.

            • [^] # Re: Hard links & comportement COW

              Posté par . Évalué à 1.

              et dans la catégorie « sisi on y a déjà pensé » il y a (outre la gestion côté serveur transparente avec cyrus) au moins horde qui permet de faire cela (publier des liens à la place d'envoyer des pièces jointes).

              Evidemment, en émission ça va, mais ça serait très lourd de gérer ça en réception (il faudrait réécrire une partie du mail, c'est possible à grand coups de mimedefang mais bon).

              De plus, ça ne gère pas de droits au niveau du lien, ça crée juste un lien unique et difficile à deviner.

              (En même temps la confidentialité d'un mail non crypté...)

    • [^] # Re: Hard links & comportement COW

      Posté par . Évalué à 2.

      Le preload, très peu pour moi !
      Clairement, il faut être sûr de son coup, si tu oublies de charger la lib ça fait quoi ?!

      Je pense que ce genre de chose a plus sa place en espace noyau (voir plus bas) ou au niveau du fs, comme http://www.digitalinfra.co.jp/20080720/hashfs.20081006.html

  • # linux-vserver's vunify,vhashify

    Posté par . Évalué à 4.

    il y a un système comme ça dans linux vserver nommé vunify/vhashify.

    Il est utilisé pour les fichiers de vservers, afin d'éviter de stockage 15 fois /bin/bash.

    Quelques infos sont ici: http://linux-vserver.org/Paper#Unification et sur le reste du wiki.

    Basiquement vhashify,
    - Est utilisé sur certains dossiers des vservers (pour éviter de faire ça sur /var).
    - fait un hash sur les fichiers rencontrés.
    - Fait une copie dans un répertoire et remplace le fichier par un lien physique vers ce répertoire. (Je ne suis pas sûr que ce soit réelement une copie, à verifier).
    - Ou, si le fichier (et donc son hash) existe déjà dans le répertoire: se contente de lier.
    - Place certains flags sur les fichiers obtenus. Pour que la modification de ceux ci casse le lien pour éviter de modifier le fichier global utilisé par tous les autres.

    Ca n'est pas directement applicable ici (le COW est géré par le noyau patché et je ne sais pas si il est utilisable en dehors d'une instance de vserver), mais peut sans doute donner des idées.

  • # Besoin criant ?

    Posté par (page perso) . Évalué à 1.

    Si vraiment ça existe pas, ça va faire le bonheur de développeurs qui vont pouvoir lancer un super nouveau projet de la mort ! :)

    • [^] # Re: Besoin criant ?

      Posté par . Évalué à 0.

      J'avoue qu'une intégration dans brtfs d'un hashfr like aurait la classe (George Abitbol si tu nous lis...)

  • # Cyrus ?

    Posté par (page perso) . Évalué à 2.

    Il y a longtemps que je n'ai pas regardé Cyrus en détail, mais je me souviens que le but du projet était d'avoir un serveur IMAP capable de gérer de très nombreuses boîtes. Il utilise un format dérivé de Maildir, mais l'espace de stockage regroupe les boîtes de tous les utilisateurs, un peu comme un SGBD. Il faudrait voir ce que c'est devenu...

    • [^] # Re: Cyrus ?

      Posté par (page perso) . Évalué à 3.

      Cyrus utilise des hards links pour gérer les redondances :
      http://cyrusimap.web.cmu.edu//imapd/overview.html#quotasup

      The Cyrus IMAP server supports quotas on storage, which is defined as the number of bytes of the relevant RFC-822 messages, in kilobytes. Each copy of a message is counted independently, even when the server can conserve disk space use by making hard links to message files. The additional disk space overhead used by mailbox index and cache files is not charged against a quota.

      • [^] # Re: Cyrus ?

        Posté par (page perso) . Évalué à 5.

        Ça ne veut rien dire : tous les serveurs IMAP un tant soit peu bien foutus utilisent des hards links, mais peu (aucun ?) ne les utilise pour partager les mails entre utilisateurs. C'est juste que si tu copies un mail dans 10 sous-dossiers, il sera stocké à un seul endroit sur ton disque.

  • # déduplication

    Posté par . Évalué à 4.

    Je pense qu'il doit être possible de faire un système de stockage qui enregistrerait une seule fois les données et des liens vers ces données. Un méchanisme à la copy-on-write pourrait être mis en place en cas d'écriture par un utilisateur.

    Est-ce que ce type de système existe (dans le libre) ? Je n'ai pas trouvé. Est-ce que vous pensez que cela est une bonne idée ? Je pense personnellement que les besoins en stockage seraient dramatiquement plus bas.

    ça s'appelle de la déduplication et c'est déjà proposé par les boites qui vendent des solutions de stockage. C'est très couramment utilisé par les solutions de backup.

    Du côté du libre je sais que c'est prévu dans zfs pour l'été prochain dans opensolaris.
    http://mail.opensolaris.org/pipermail/zfs-code/2009-March/00(...)

  • # Fonctionnalité très importante

    Posté par (page perso) . Évalué à 2.

    Bonjour à tous,

    Effectivement cette fonctionnalité recherchée est extrêmement importante. Car elle permet de réduire de plus 50% l'espace disque d'une structure avec 200 BAL.

    Je prends l'exemple de Lotus Notes avec la fonctionnalité DAOS qui permet indexer toutes les pièces jointes dans une base de données.

    D'autres serveurs de courriers closed-source proposent cette fonctionnalité.
    C'est dommage qu'en OpenSource on ne trouve pas cette fonctionnalité en version stable prêt pour la production!


    J'espère que cela va changer

    à bientôt

  • # DBmail does it

    Posté par . Évalué à 3.

    Hello world,

    Voici mes 2 cents! Il existe un projet qui se nomme dbmail [www.dbmail.org] et qui supporte dans sa branch devel la capacite de stocker une seule fois un mail. Cette capacite s'appele single-instance-storage.

    Voici la page annoncant pour cette fonctionalite dans la branch 2.3.x [http://www.dbmail.org/index.php?page=news&id=41].

    tick Done ;-)

  • # oui ça existe :-)

    Posté par . Évalué à 1.

    http://www.archiveopteryx.org/overview

Envoyer un commentaire

Suivre le flux des commentaires

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