No space left on device

[RiPSO]

Coucou

Je suis en train de pousser mon serveur de test pour voir un peu les limites.

Pour ça j'ai créé un programme (en python, mais peu importe le language en fait... :mrgreen: ) qui créé un max de fichiers dans le même repertoire. J'avais défini une boucle de 5M (histoire de pas faire une boucle infinie et pas blinder le HDD) avec un affichage tous les 10K pour savoir où j'en suis.

Opération totale en théorie : 5M de fichiers / 19.7Go

Je lance et plusieurs minutes après j'ai une erreur No space left on device exactement sur le 4.055.480 ème fichier créé...

Un petit df -h m'informe que ma partition est occupée à 31% et qu'il me reste 47G de dispo. 8O

Quelqu'un a déjà eu le même problème??


[edit] Je précise que le serveur tourne sur une debian Lenny et que c'est une machine dédiée de ce qu'il y a de plus banal, un serveur de test quoi... Voici les specs :
CPU : Atom 230/D410 à 1,6 GHz FSB 533 MHz 512 Ko de cache L2
HDD : 80Go SATA2
RAM : 1Go DDR2

 

[spout]

Je pense que tu es à la limite du système de fichier pour le nombre max de fichiers par répertoire, ça dépend de celui que tu utilises (Ext, ReiserFS, ...)

 

[RiPSO]

Tu penses pas que ça m'aurait donné un message d'erreur en rapport?

J'avais déjà fais le test du nombre max de repertoires par repertoire et le message d'erreur était assez explicite du style "casse toi avec tous tes répertoires là!" (enfin c'est une traduction approximative hin :mrgreen: )

 

[RiPSO]

Pour info, un

echo "coucou" > coucou.txt

via le shell me retourne

-bash: coucou.txt: Aucun espace disponible sur le périphérique

[edit] Et testé dans un répertoire différent donc c'est pas ça :cry:

 

[jcaron]

"df -i" va probablement t'expliquer que tu es à court d'inodes. C'est un problème assez classique si la taille moyenne de tes fichiers est inférieure à ce qui était prévu lors de la création du filesystem. Seul moyen de corriger: effacer entièrement et recréer le filesystem en précisant avec -i le ratio taille/inodes voulu.

Au delà de ça, il est généralement fortement sous-optimal de mettre beaucoup de fichiers dans un répertoire unique, il vaut mieux utiliser une structure arborescente et limiter à quelques centaines le nombre de fichiers/dossiers par répertoire.

Jacques.

 

[RiPSO]

Bingo!! Merci

Bon bin je profite de ce topic car si je fais ce genre de tests c'est parcequ'en ce moment je cherche les meilleures solutions pour me passer d'une base de données. Le but actuel c'etait de passer par la RAM et le systeme de fichiers pour l'écriture et seulement la RAM pour la lecture. Je souhaitais passer par le système de fichier car en cas de mauvaise écriture je trouvais que ça limitait la casse, et que ca facilitait grandement la gestion.

Ok pour le coté sous-optimal, je vais me rabattre sur mes premiers choix de diviser par repertoires. Par contre si je suis limité par le filesystem ca va me poser soucis. Tu peux m'orienter vers des manips que je me renseigne? Y'a un impact sur les performances à grossir le nombre max d'inodes? Si je le passe à un chiffre démesuré ça peut avoir des conséquences? (là il est à 5M... si je le passe à 1 milliard par exemple)

 

[jcaron]

Sur les perfs, non, mais ça prend de la place, c'est tout... Un inode fait 128 octets par défaut en ext3, donc 1 milliard d'inodes = 128 Go utilisés... Chaque fichier ou dossier = 1 inode.

Pour le reste de tes questions (ou plutôt interrogations), ça aiderait si on avait un peu plus de contexte, en particulier pourquoi tu veux te passer d'une base de données (mon expérience est que c'est très rarement pertinent). Si c'est une question de perfs, un peu d'optimisation des requêtes permet généralement d'arriver à des performances identiques voire meilleures qu'un tas de petits fichiers. Et en ajoutant un cache (genre memcache), c'est encore mieux.

Mais si tu veux vraiment avoir tes propres petits fichiers, suivant tes besoins tu peux utiliser soit une arbo de fichiers, soit éventuellement des fichiers dans lesquels tu vas "seeker" au bon endroit (si les enregistrements ont une taille fixe et que les valeurs d'index sont contigues, bien sûr). Tu peux aussi utiliser des fichiers dbm.

Evidemment, je suppose que tu as pensé aux problématiques de locking pour les accès par des processus concurrents? Et à la "scalability" si tu as besoin de dépasser une seule machine?

Jacques.

 

[RiPSO]

Pour la place ça ne me semble pas être un soucis. En ce qui concerne l'inode c'est de la place réservée ou alors ça prend de la place à chaque création d'inode?
Ma recherche c'est une utilisation en RAM au maximum et une sauvegarde sur disque dur au cas où le serveur plante que je puisse recharger la RAM au boot.

Si je veux me passer d'une base de données c'est pour la simple raison que ça ajoute quelque chose qui peut planter. En gros je pars du principe que si t'as 10 softs utilisés par ton programme t'as 10 possibilités que ton programme merde. Alors oui c'est à ca que ca sert entre autre la detection d'erreur mais tant qu'a faire, un file system ne plante pas donc dans ma tete ça a fait tilt :mrgreen:

Concernant les arbos j'ai pour habitude de decouper à l'arrache caractere par caractere genre un identifiant 1628 irai par exemple dans un repertoire ./1/6/2/8/id1628/ . Ca permet de contourner la limitation du nombre max de repertoires par repertoire. (La seule limitation que j'ai trouvé à cela c'est la limitation de la taille en nombre de caracteres du chemin du repertoire)
J'avais pensé à un fichier bien seeké mais ca m'ajoute une possibilité de perte totale/partielle en cas de plantage de serveur en cours d'ecriture donc j'en suis venu à un fichier de conf par utilisateur, ce qui en cas de probleme, je pense, limitera la casse à un seul utilisateur qui verra sa conf resetée.

Oui pour le locking c'est réglé assez simplement (enfin théoriquement) et problème de scalabilité était ma toute première réflexion et est la plus importante à mes yeux.
Là mon soucis actuel c'est :
1/ de me faire une idée sur toutes les contraintes engendrées par l'abandon d'un système à base de données (et qui, je suis conscient, reste le moyen le plus pratique d'enregistrer et faire appel rapidement à des données).
2/ trouver toutes les limites avant de retirer les bdd de mon code (j'aime pas travailler plusieurs heures pour voir au final que ça fonctionne pas et devoir coller une rustine crados pour que ça tourne :mrgreen: )

 

[jcaron]

La place est réservée pour les inodes dès la création du filesystem (sinon il n'y aurait pas besoin de préciser de combien on en a besoin).

Sérieusement, un serveur SQL décent comme mysql ou postgresql, c'est quand même très solide, et ça a été un peu beaucoup plus testé et éprouvé que n'importe quel code que tu vas écrire. Et ton OS va spontanément garder en RAM tout ce qu'il a lu sur disque, donc de ce côté là, "ça, c'est fait", comme dirait l'autre.

Si tu pars sur l'arbo, tu peux sans problème y aller par 2 chiffres, voire 3. Tu peux aussi passer en hexa tant que tu y es.

Si tu seekes dans un fichier pour écrire juste un petit bout, tu ne vas jamais perdre l'ensemble du fichier. En fait, tu as moins de chances de perdre quoi que ce soit comme ça qu'en créant des fichiers. Mais une base de données décente (donc ACID) te garantira tout ça de façon encore plus sûre.

Le locking c'est pas si évident que ça... D'une part parce qu'il faut que ça résiste à un plantage éventuel (donc que ça ne laisse pas des locks derrière soit), et d'autre part parce que suivant la façon dont est fait le locking, ça peut poser des problèmes de concurrence et donc de performances. Ce qui donne les différences de perfs entre les tables myisam et innodb quand tu as beaucoup d'écritures par exemple.

En termes de "scalabilité", le gros avantage d'une base SQL c'est qu'elle peut être sur un autre serveur, et partagée par plusieurs frontaux, ce qui sera nettement plus problématique avec un système de fichiers. Si ta base SQL devient trop lourde pour un seul serveur, tu peux ensuite faire du partitionnement de ta base SQL sur plusieurs serveurs, ou de la réplication, etc. Bref, c'est nettement plus souple dès le départ. Et comme je disais précédemment, une bonne couche de memcached peut largement aider à résoudre des problèmes de performance.

Bref, les fichiers, c'est amusant pour des choses un peu grosses, peu ou pas modifiées, et avec un accès individuel par un index unique (des images par exemple), mais pour le reste, tu vas vite le regretter (quand tu va vouloir faire des stats, une petite modif rapide sur plein de fichiers, que tu vas devoir utiliser plusieurs machines, etc.).

Jacques.