Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Discussions Générales Creation et suppression de petits fichiers. Quel filesystem?

Creation et suppression de petits fichiers. Quel filesystem?

15 réponses
Avatar
Kevin Denis
Bonjour,

j'ai une application qui doit creer et supprimer un tres grand
nombre de petits fichiers (et quelques uns de toutes tailles, de
petit a tres gros). Fichiers ranges a plat (pas de sous repertoires).

Je m'interroge sur le filesystem le plus adapte a cet exercice.

1er cas: peu importe. Je fais confiance au cache de linux, la majorite
des fichiers sont crees en RAM, et le cache ne les ecrit pas sur le
disque car ils sont supprimes rapidement. Y'a t'il une option de
montage particuliere? noatime? async?

2e cas: ext3 car les ecritures/suppressions se feront dans le
journal, ce qui est tres rapide. Ou plutot ext2 car justement,
on peut esperer que les traitements ecriture/suppression n'auront
lieu que dans la RAM. Lequel est le meilleur?

3e cas: un autre filesystem? Lequel? reiserfs? xfs? pourquoi?

4e cas: vaut il mieux utiliser une partition, un fichier, ou
un tmpfs?

Merci
--
Kevin

--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Basile Starynkevitch [news]
Bonjour

On 2005-10-18, Kevin Denis wrote:

j'ai une application qui doit creer et supprimer un tres grand
nombre de petits fichiers (et quelques uns de toutes tailles, de
petit a tres gros). Fichiers ranges a plat (pas de sous repertoires).



Je m'interroge sur le filesystem le plus adapte a cet exercice.



Reiserfs est connu pour permettre un grand nombre (plusieurs centaines
de milliers au moins, voire plusieurs dizaine de millions) de fichiers
dans le même repertoire, situation qui est sensée faire souffrir un
ext3. Il est possible que d'autres filesystèmes le permettent aussi
(XFS, JFS?)


Dans la pratique, je n'ai pas l'experience de ce genre de
situation. Mes repertoires les plus gros ont contenus (durant une
journée) environ 60000 fichiers, et ca tenait encore la route avec
ext3.

Cela étant dit, peut-être que d'autres solutions (par exemple un
fichier indexé Gdbm, ou même une table sous MySQL) pourraient convenir
aussi.

Par curiosité, j'aimerais bien savoir quelle genre d'application
est-ce... Mon plus gros essai était le petit programme manydl.c
disponible sur ma page Web (que j'ai écris pour tester qu'on peut
faire beaucoup -des milliers- de dlopen ensemble, et c'est
effectivement le cas; il genère une foule de fichiers genf*.c compilés
en autant de genf*.so qui sont dlopen-és ensemble).

Il est possible que la sauvegarde ou la restauration d'un répertoire
contenant des milliers de fichiers soit lente...

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile(at)starynkevitch(dot)net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Dominique ROUSSEAU
Le mar, 18 oct 2005 at 12:00 GMT, Kevin Denis a écrit :
Bonjour,

j'ai une application qui doit creer et supprimer un tres grand
nombre de petits fichiers (et quelques uns de toutes tailles, de
petit a tres gros). Fichiers ranges a plat (pas de sous repertoires).


[...]
4e cas: vaut il mieux utiliser une partition, un fichier, ou
un tmpfs?



Si les fichiers sont destinés à ne pas "vivre vieux" et que leur perte
(reboot inopiné, ...) ne porte pas à conséquence, un tmpfs sera
certainement le mieux.
Pour le cas des "tres gros", ça risque d'être un peu problématique, sauf
à créer ton tmpfs très grand, et compter sur le fait que ça sera swappé
si nécessaire.


Dom

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Yves
Kevin Denis a écrit :
j'ai une application qui doit creer et supprimer un tres grand
nombre de petits fichiers (et quelques uns de toutes tailles, de
petit a tres gros). Fichiers ranges a plat (pas de sous repertoires).

Je m'interroge sur le filesystem le plus adapte a cet exercice.



Il faudrait faire quelques tests à mon avis, mais il est possible que
ext3 avec l'option data=journal soit intéressante dans ce cas là...
L'article date un peu, mais contient pas mal d'infos intéressantes:

http://www-128.ibm.com/developerworks/linux/library/l-fs8.html

Yves

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Emmanuel Florac
Le Tue, 18 Oct 2005 19:53:20 +0000, Basile Starynkevitch [news] a
écrit :


Reiserfs est connu pour permettre un grand nombre (plusieurs centaines
de milliers au moins, voire plusieurs dizaine de millions) de fichiers
dans le même repertoire, situation qui est sensée faire souffrir un
ext3. Il est possible que d'autres filesystèmes le permettent aussi
(XFS, JFS?)



J'ai testé extensivement ext3, reiserfs et xfs dans différents cas de
figures. ext3 est TOUJOURS le plus mauvais dans TOUS lES CAS de figure.
reiserfs est le mieux quand il y a beaucoup de petits fichiers. XFS est
plus reformant quand il y a beaucoup de gros ou très gros (plusieurs
dizaines de mégas) fichiers.
Je n'ai pas testé JFS. EN tout cas je n'utiliserai en aucun cas ext2/3
quelle que soit l'application....

--
Si non confectus non reficiat.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Michel Arboi
On Tue Oct 18 2005 at 14:00, Kevin Denis wrote:

j'ai une application qui doit creer et supprimer un tres grand
nombre de petits fichiers (et quelques uns de toutes tailles, de
petit a tres gros). Fichiers ranges a plat (pas de sous
repertoires).



Quand tu parles de "grand nombre", tu veux dire qu'à un instant donné,
tu as une myriade de fichiers ? Ou ils sont effacés au fur et à mesure
et tu en as finalement peu qui restent ?
Dans le premier cas: pourquoi pas de sous-répertoire ? Tu ne maîtrises pas
l'application en question ?

Je m'interroge sur le filesystem le plus adapte a cet exercice.



S'il faut vraiment tout mettre à plat, reiserfs sera plus rapide
qu'ext3. Il est certainement plus fragile car plus complexe -- j'ai
déjà eu des phénomènes bizarres. Si c'est un répertoire temporaire
avec des fichiers à courte durée de vie, ça n'a peut-être pas
d'importance.

1er cas: peu importe. Je fais confiance au cache de linux, la majorite
des fichiers sont crees en RAM, et le cache ne les ecrit pas sur le
disque car ils sont supprimes rapidement. Y'a t'il une option de
montage particuliere? noatime? async?



async est là par défaut. noatime si tu n'as pas besoin de mettre à
jour les dates d'accès (ce qui semble logique si les fichiers sont
destinés à être effacés rapidement). Eventuellement commit=xxx avec
xxx = une valeur supérieur à 5 (défaut) ; à tester, je ne garantis
rien.
journal=writeback pourrait aussi accélérer, avec un risque de
corruption de données sur un reboot violent (sans importance ?)

Je ne sais pas si un journal séparé sur un autre device pourrait
apporter un gain de performances.

2e cas: ext3 car les ecritures/suppressions se feront dans le
journal, ce qui est tres rapide. Ou plutot ext2 car justement,
on peut esperer que les traitements ecriture/suppression n'auront
lieu que dans la RAM. Lequel est le meilleur?



À l'instinct, je jouerais plutôt ext3. Mais c'est facile à comparer,
tu n'as même pas besoin de refaire un mkfs, juste démonter proprement
l'ext3 et le remonter comme ext2.

3e cas: un autre filesystem? Lequel? reiserfs? xfs? pourquoi?



Voir plus haut la remarque pour les myriades de petits fichiers.
Je n'ai pas d'expérience sur XFS ou JFS.

4e cas: vaut il mieux utiliser une partition, un fichier, ou
un tmpfs?



En pratique, si les fichiers sont effacés rapidement et si tu as
suffisamment de mémoire sur ta machine, je ne pense pas que ça change
grand chose.

--
http://arboi.da.ru/
PGP key ID : 0x0BBABA91 - 0x1320924F0BBABA91
Fingerprint: 1048 B09B EEAF 20AA F645 2E1A 1320 924F 0BBA BA91

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Stephane Chazelas
2005-10-18, 21:00(+00), Emmanuel Florac:
Le Tue, 18 Oct 2005 19:53:20 +0000, Basile Starynkevitch [news] a
écrit :


Reiserfs est connu pour permettre un grand nombre (plusieurs centaines
de milliers au moins, voire plusieurs dizaine de millions) de fichiers
dans le même repertoire, situation qui est sensée faire souffrir un
ext3. Il est possible que d'autres filesystèmes le permettent aussi
(XFS, JFS?)



J'ai testé extensivement ext3, reiserfs et xfs dans différents cas de
figures. ext3 est TOUJOURS le plus mauvais dans TOUS lES CAS de figure.


[...]

As-tu testé en 2.6 apres tune2fs -O dir_index et e2fsck -fD?

(utilisation de hashed b-trees pour les repertoires).

--
Stéphane

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Emmanuel Florac
Le Wed, 19 Oct 2005 08:18:37 +0000, Stephane Chazelas a écrit :


As-tu testé en 2.6 apres tune2fs -O dir_index et e2fsck -fD?



Non, il est vrai, je n'ai pas retesté avec le 2.6. Mais je n'ai aucune
raison de me plaindre de reiserfs et XFS, maintenant.

--
entia non sont multiplicanda praeter necessitatem.
John Ponce of Cork.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Kevin Denis
Le 19-10-2005, Michel Arboi a écrit :

j'ai une application qui doit creer et supprimer un tres grand
nombre de petits fichiers (et quelques uns de toutes tailles, de
petit a tres gros). Fichiers ranges a plat (pas de sous
repertoires).



Quand tu parles de "grand nombre", tu veux dire qu'à un instant donné,
tu as une myriade de fichiers ? Ou ils sont effacés au fur et à mesure
et tu en as finalement peu qui restent ?



a terme, ils disparaissent tous.

Dans le premier cas: pourquoi pas de sous-répertoire ? Tu ne maîtrises pas
l'application en question ?



L'application est HAVP (www.server-side.de). C'est un proxy antivirus.
Il recupere les fichiers, les cree sur une partition, les scanne,
puis les efface.
Il est prevu que tous les fichiers soient appeles:
# SCANTEMPFILE /var/tmp/havp/havp-XXXXXX
Pas de sous repertoires. La vitesse de creation/destruction est donc
dependante de la taille des fichiers, de la vitesse du scan et du
nombre de clients derriere qui le sollicite.
La majorite des fichiers sera sans doute tres petite (de la taille d'une
page web donc de l'ordre du ko) et certains gros, voir tres gros (si
quelqu'un telecharge une image iso par HTTP).

Je m'interroge sur le filesystem le plus adapte a cet exercice.



S'il faut vraiment tout mettre à plat, reiserfs sera plus rapide
qu'ext3. Il est certainement plus fragile car plus complexe -- j'ai
déjà eu des phénomènes bizarres. Si c'est un répertoire temporaire
avec des fichiers à courte durée de vie, ça n'a peut-être pas
d'importance.



Effectivement, aucun de ces fichiers temporaire n'est important.

Par contre, quel est le fs le plus fragile car plus complexe, ext3
ou reiserfs?

1er cas: peu importe. Je fais confiance au cache de linux, la majorite
des fichiers sont crees en RAM, et le cache ne les ecrit pas sur le
disque car ils sont supprimes rapidement. Y'a t'il une option de
montage particuliere? noatime? async?



async est là par défaut. noatime si tu n'as pas besoin de mettre à
jour les dates d'accès (ce qui semble logique si les fichiers sont
destinés à être effacés rapidement). Eventuellement commit=xxx avec
xxx = une valeur supérieur à 5 (défaut) ; à tester, je ne garantis
rien.



Effectivement, ca semble interessant comme variable. Je
pourrais mettre un commit a 1mn.

journal=writeback pourrait aussi accélérer, avec un risque de
corruption de données sur un reboot violent (sans importance ?)



sans importance effectivement.

Je ne sais pas si un journal séparé sur un autre device pourrait
apporter un gain de performances.



ext2 dans ces cas de figure serait plus rapide?

2e cas: ext3 car les ecritures/suppressions se feront dans le
journal, ce qui est tres rapide. Ou plutot ext2 car justement,
on peut esperer que les traitements ecriture/suppression n'auront
lieu que dans la RAM. Lequel est le meilleur?



À l'instinct, je jouerais plutôt ext3. Mais c'est facile à comparer,
tu n'as même pas besoin de refaire un mkfs, juste démonter proprement
l'ext3 et le remonter comme ext2.



Pour l'instant je teste dans un fichier loop, donc je peux
formatter tant et plus. Mais mes tests en reduit ne me montre
pas trop de differences de performances.

3e cas: un autre filesystem? Lequel? reiserfs? xfs? pourquoi?



Voir plus haut la remarque pour les myriades de petits fichiers.
Je n'ai pas d'expérience sur XFS ou JFS.

4e cas: vaut il mieux utiliser une partition, un fichier, ou
un tmpfs?



En pratique, si les fichiers sont effacés rapidement et si tu as
suffisamment de mémoire sur ta machine, je ne pense pas que ça change
grand chose.



Ok, merci

--
Kevin

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Jeremy JUST
On 18 Oct 2005 19:53:20 GMT
"Basile Starynkevitch [news]" wrote:

Cela étant dit, peut-être que d'autres solutions (par exemple un
fichier indexé Gdbm, ou même une table sous MySQL) pourraient convenir
aussi.



Oui, ça peut être bien d'utiliser son propre système de fichiers pour
ce genre de cas.

J'ai fait un essai sur un nombre moyen de fichiers (environ 55000, je
crois) de chacun 2-4 ko: dans un programme Perl, je les ai stockés dans
un DB_file (fichier Berkeley), en utilisant leur nom comme clef, et en
mettant leur contenu, compressé avec Zlib en valeur.

Par rapport à un stockage de fichiers compressés avec gzip sur un
filesystem UFS, l'accès était environ 2 à 3 fois plus rapide, et prenait
sensiblement la même place (à 20 Mo près).
Autre avantage: il est très rapide de sauvegarder un fichier de
200 Mo, tandis que des milliers de petits fichiers font ramer la plupart
des systèmes de sauvegarde.
En contrepartie, si les fichiers doivent être modifiés souvent, le
DB_File prendra plus d'espace de sauvegarde (il paraîtra complètement
modifié à chaque fois).



--
Jérémy JUST

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Pelletreau Olivier
le Wed, 19 Oct 2005 11:34:06 +0000, Kevin Denis tergiversait:

En pratique, si les fichiers sont effacés rapidement et si tu as
suffisamment de mémoire sur ta machine, je ne pense pas que ça change
grand chose.



Ok, merci




Pourquoi pas un ramdisk directement? au moins tu es sur qu'il sera en
mémoire, en cas d'arrêt, propre ou pas, tu perds tout, mais quelle
importance?

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
1 2