›

Nombre de dossiers ou fichiers dans un dossier

muqaddarmuqaddar Administrateur
03:30 modifié dans Langages Web & serveurs #1
Salut,

Sur un serveur UNIX (Linux), quel est le nombre maximal de dossiers et/ou fichiers qu'on peut mettre dans un dossier ? J'avais cru lire que c'était 32000, mais j'ai comme un doute, je trouve cette limite basse.

Tant que j'y suis, je pose la même question pour OS X.

Réponses

  • AliGatorAliGator Membre, Modérateur
    03:30 modifié #2
    Je pense que ça ne dépend pas du noyau à  proprement parler (UNIX), mais du FileSystem.
    Selon les FileSystems, certains pourront avoir des noms plus ou moins longs pour les fichiers et dossiers, et plus ou moins de fichiers dans leur répertoires, ou un nombre maximum de niveaux dans leur hiérarchie, etc

    Par exemple la doc Apple sur ces limites en question concernant HFS+
    Nombre maximum de fichiers (ou fichiers et dossiers) dans un dossier (toutes les versions Mac OS X)
    = jusqu'à  2,1 milliards (2^31)

  • muqaddarmuqaddar Administrateur
    03:30 modifié #3
    Je préfère ce genre de limites... Je commençais à  m'affoler pour un site que j'ai chez un hébergeur.
    D'après ce que je viens de lire, c'est grosso-modo la même chose sur les Linux, et ça dépend su système (32 ou 64 bits).
  • muqaddarmuqaddar Administrateur
    03:30 modifié #4
    Bon, je me suis fais avoir comme un bleu.  :P
    Il y a bien une limite de 32000 nodes pour le filesystem Ext3:
    http://blog.zachwaugh.com/post/309921185/ext3-filesystem-sub-directory-limit

    Je vais trouver une parade en modifiant un plugin (celui qui crée les dossiers justement) pour créer des sous-dossiers.
  • AliGatorAliGator Membre, Modérateur
    03:30 modifié #5
    Pour info dans la plupart des serveurs qui stocke un nombre conséquent de fichiers de toute façon c'est ce qu'ils font.
    Par exemple nous pour les plus de 100 000 photos de plats qu'on a, on ne les stocke pas tous dans le même dossier sur notre S3 (heureusement), mais on les découpe par sous-dossier de 100 fichiers.
  • muqaddarmuqaddar Administrateur
    décembre 2011 modifié #6
    La technique trouvée, là , c'est de découper de cette façon:

    25678/image.jpg => 2/5/6/7/8/image.jpg

    Ce n'est peut-être pas très propre, mais c'est diablement efficace.

    PS: tu dis avoir 100000 plats ? Pas plus ? Je croyais que vous aviez 100000 membres. ça voudrait donc dire qu'un membre ne poste qu'un plat  en moyenne ?
  • AliGatorAliGator Membre, Modérateur
    03:30 modifié #7
    Tu veux dire que t'as pléthore de dossiers, et une seule image par dossier qui s'appelle tjs "image.jpg" ?

    Alors du coup c'est trop découpé je pense.
    Pourquoi pas 256/78/image.jpg ?
  • muqaddarmuqaddar Administrateur
    03:30 modifié #8
    J'ai 3 dossiers image par dossier d'enregistrement en BDD (chaque dossier a un dossier full/ thumb/ et l'image originale). Je peux générer d'autres versions au besoin.
  • DrakenDraken Membre
    03:30 modifié #9
    dans 1324141590:

    PS: tu dis avoir 100000 plats ? Pas plus ? Je croyais que vous aviez 100000 membres. ça voudrait donc dire qu'un membre ne poste qu'un plat  en moyenne ?

    Oui, moi par exemple !

  • AliGatorAliGator Membre, Modérateur
    03:30 modifié #10
    dans 1324141590:

    PS: tu dis avoir 100000 plats ? Pas plus ? Je croyais que vous aviez 100000 membres. ça voudrait donc dire qu'un membre ne poste qu'un plat  en moyenne ?
    Oui oui c'est que ça augmente tellement vite, là  j'ai pas cité les vrais chiffres...
    On doit en être à  pas loin de 150k plats à  peu près aujourd'hui, j'ai pas les chiffres en tête
  • DrakenDraken Membre
    03:30 modifié #11
    Tu devrais ajouter un compteur sur l'application, genre le truc du téléthon avec les chiffres des donations en temps (pas tout à  fait) réel.
  • muqaddarmuqaddar Administrateur
    03:30 modifié #12
    dans 1324147407:

    dans 1324141590:

    PS: tu dis avoir 100000 plats ? Pas plus ? Je croyais que vous aviez 100000 membres. ça voudrait donc dire qu'un membre ne poste qu'un plat  en moyenne ?
    Oui oui c'est que ça augmente tellement vite, là  j'ai pas cité les vrais chiffres...
    On doit en être à  pas loin de 150k plats à  peu près aujourd'hui, j'ai pas les chiffres en tête


    ça veut quand-même dire que y'a un paquet d'utilisateurs qui téléchargent et s'inscrivent "juste pour voir".
  • AliGatorAliGator Membre, Modérateur
    03:30 modifié #13
    Oui il y en a qui regardent sans s'inscrire ou qui s'inscrivent mais ne poste pas bcp, c'est normal. Et il y en a en contraste qui postent plusieurs fois par jour.

    Après, d'après Flurry on a un taux de rétention plus élevé que les autres apps de ce genre (réseaux sociaux, etc) et une des rares apps à  avoir 5 étoile sur l'AppStore :) Alors évidemment y'a des drogués à  FR qui postent tout le temps et à  côté de ça certains qui ne postent presque jamais, on a un peu tous les profils c'est normal ça s'équilibre ;)
  • muqaddarmuqaddar Administrateur
    #14
    Bon, j'avais prévu un nouveau système illimité en nombre de dossiers, et je me suis fait chatier par mon hébergeur.



    Chaque vin ayant un UUID, je découpe celui-ci en autant de dossiers que nécessaire.

    A -> B -> F -> 3 ...



    Je me disais, je suis assuré d'être tranquille à  vie sur le nombre de noeuds par dossier.



    C'était sans compter sur mon hébergeur qui vient de me dire qu'il allait désactiver le backup de mon compte parce que j'avais atteint "200K directories"... gloups !



    Du coup, ça sent le serveur dédié... et les coûts qui vont avec.



    Je suppose que vous êtes déjà  en dédié sur FR.
  • muqaddarmuqaddar Administrateur
    #15
    Une autre solution serait p-e de faire un crontab + rsync de leur serveur vers un serveur à  moi, ce qui éviterait de prendre un dédié, m'occupant moi-même de la sauvegarde. C'est possible ça ? rsync sait synchroniser un dossier de serveur à  serveur utilisant le canal SSH ? Avec une crontab, ça doit le faire ?
  • AliGatorAliGator Membre, Modérateur
    juillet 2012 modifié #16
    On est chez gandi pour l'hébergement du site web et WS pour FR (donc pas dédié si je dis pas de bétises). Et Amazon S3 pour le stockage des images.

    Les répertoires sont découpés par séries de 100.
  • muqaddarmuqaddar Administrateur
    juillet 2012 modifié #17
    Diable, j'ai complètement oublié cet Amazon S3 dont j'ai entendu parlé des milliers de fois... ça peut-être ma solution à  moindre coût (ça n'a pas l'air très cher).



    En plus je sais que ça s'interface en 2 lignes de code avec un gem Rails.
  • muqaddarmuqaddar Administrateur
    juillet 2012 modifié #18
    'AliGator' a écrit:


    Les répertoires sont découpés par séries de 100.




    ça ça m'étonne quand-même parce qu'à  partir du moment ou tu passes chez S3, il me semble que S3 fait sa cuisine interne pour gérer ce genre de chose.



    http://stackoverflow.com/questions/3980968/s3-limit-to-objects-in-a-bucket
  • yoannyoann Membre
    #19
    Une limite qui existe au niveau du kernel par contre, c'est le nombre de fichier ouvert autorisé. C'est cependant réglable.



    La technique du 1/2/3/4/data est plus que recommandé pour éviter les problèmes de lenteurs d'accès et les problèmes de maintenance.
  • AliGatorAliGator Membre, Modérateur
    #20
    'muqaddar' a écrit:


    ça ça m'étonne quand-même parce qu'à  partir du moment ou tu passes chez S3, il me semble que S3 fait sa cuisine interne pour gérer ce genre de chose.
    Oui oui ce n'est pas nous qui découpons (enfin je crois, c'est pas moi qui m'occupe de la partie serveur). C'est juste un fait que j'ai remarqué, chaque photo est associé à  un ID chez nous (mediaID), et il me semble que la version "thumb" de la photo 12345 est dans le répertoire "thumb/123/12345.jpg", la version "full" dans le répertoire "full/123/12345.jpg".
  • muqaddarmuqaddar Administrateur
    #21
    Moi je fais plutôt l'inverse en général:



    1/2/3/4/5/thumb/image.jpg

    1/2/3/4/5/full/image.jpg



    Bon, j'ai trouvé mon devoir de vacances dans les Alpes: S3 !
  • yoannyoann Membre
    #22
    'muqaddar' a écrit:


    Moi je fais plutôt l'inverse en général:



    1/2/3/4/5/thumb/image.jpg

    1/2/3/4/5/full/image.jpg




    D'un point de vue administrateur système je ne ferais surtout pas ça.



    Il est bien plus logique d'avoir une branche original puis une branche thumb avec les même sous arbres. Ce sont de famille d'objet différent. Si tu souhaite migrer tes données supprimer tout tes thumb pour les recréer avec ton nouveau script de miniature, c'est bien plus simple de supprimer la racine de l'arbre que ses feuilles.



    De la même manière, ton fichier final doit se nommer du nom complet de la ressource, il ne doit en aucun cas avoir un nom identique d'un fichier à  l'autre. Cela te sera utile si un jour tu cherche à  récupérer un export plat de toutes tes ressources. Cela servira aussi en cas de crash de disque, si tu passe en récup et que tu ne récupère que les fichiers sans la hiérarchie de disque, tu sera également content. Et dernier point, avec le nom complet au final, tu t'autorise à  avoir une profondeur de dossier éventuellement plus faible que le nom du fichier en lui même, ce qui sera utile si un jour tu remplace tes UID par des UUID pour plus de sécurité.
  • muqaddarmuqaddar Administrateur
    #23
    'yoann' a écrit:


    D'un point de vue administrateur système je ne ferais surtout pas ça.



    Il est bien plus logique d'avoir une branche original puis une branche thumb avec les même sous arbres. Ce sont de famille d'objet différent. Si tu souhaite migrer tes données supprimer tout tes thumb pour les recréer avec ton nouveau script de miniature, c'est bien plus simple de supprimer la racine de l'arbre que ses feuilles.




    Oui, c'est vrai pour ce cas.

    Mais si on veut supprimer un seul record et les 3 fichiers dépendants, il ne faut parcourir qu'une seule arbo et non 3.

    (mais bon, sinon, c'est mon gem qui gère ça en interne, je ne vais pas aller le réécrire)


    'yoann' a écrit:


    De la même manière, ton fichier final doit se nommer du nom complet de la ressource, il ne doit en aucun cas avoir un nom identique d'un fichier à  l'autre. Cela te sera utile si un jour tu cherche à  récupérer un export plat de toutes tes ressources. Cela servira aussi en cas de crash de disque, si tu passe en récup et que tu ne récupère que les fichiers sans la hiérarchie de disque, tu sera également content.




    Mais qui t'a dit que mes noms de fichiers n'étaient pas uniques ? Bien sûr qu'ils le sont !




    'yoann' a écrit:


    Et dernier point, avec le nom complet au final, tu t'autorise à  avoir une profondeur de dossier éventuellement plus faible que le nom du fichier en lui même, ce qui sera utile si un jour tu remplace tes UID par des UUID pour plus de sécurité.




    En fait actuellement, l'UUID du record concerné en base sert de path, (A/E/1/F/....), et le nom du fichier image est également un autre UUID (AE1F-...-FF.jpg).
  • yoannyoann Membre
    #24
    'muqaddar' a écrit:


    Mais qui t'a dit que mes noms de fichiers n'étaient pas uniques ? Bien sûr qu'ils le sont !




    Bah toi ^^






    'muqaddar' a écrit:


    Moi je fais plutôt l'inverse en général:



    1/2/3/4/5/thumb/image.jpg

    1/2/3/4/5/full/image.jpg




    C'est à  ce commentaire que je répondais ^^
  • muqaddarmuqaddar Administrateur
    #25
    'yoann' a écrit:


    Bah toi ^^




    Tu me montreras où... image/wink.png' class='bbc_emoticon' alt=';)' />
  • yoannyoann Membre
    #26
    'muqaddar' a écrit:


    Tu me montreras où... image/wink.png' class='bbc_emoticon' alt=';)' />




    Tu blague là  ? Tu vois pas la citation juste en dessous du "Bah toi ^^" ?!
  • muqaddarmuqaddar Administrateur
    juillet 2012 modifié #27
    Tu aurais pu te douter que c'était un exemple de nommage... comme "1/2/3/4/5"... image/kiss.gif' class='bbc_emoticon' alt=':-*' />
Connectez-vous ou Inscrivez-vous pour répondre.