Bonjour,
J'ai une question à deux balles pour les utilisateurs de CoLinux. J'ai au boulot une application Windows qui (accrochez-vous) accède à un répertoire contenant 600.000 fichiers. Autant vous dire que le NTFS ne tient pas la route. Je ne dis pas ça comme un anti-Microsoft de base, Microsoft ne recommande pas de mettre des centaines de milliers de fichiers dans un même répertoire, et de nombreux systèmes de fichiers libres auraient le même problème. C'est plutôt l'application qui n'a pas été conçue pour un volume de données de cette taille.
Bref, je me demandais si utiliser CoLinux+Samba+ReiserFS serait une solution. J'ai fait un test chez moi (Linux pur) et le temps d'accès pour un fichier dans un répertoire des 500.000 éléments est négligeable (à comparer à plusieurs minutes pour un "fopen" sur du NTFS).
Utiliseriez-vous CoLinux en prod (point de vue stabilité) ?
Forum Linux.général Stabilité CoLinux
5
oct.
2004
# Ben ...
Posté par kesako . Évalué à 2.
BTW: Ton test est en "linux pur" , ce n'est pas credible.
[^] # Re: Ben ...
Posté par Gniarf . Évalué à 1.
[^] # Re: Ben ...
Posté par kesako . Évalué à 3.
Là il s'agit de gerer 600 000 fichiers . Si colinux se viande en boussillant les fichiers , ce ne sera pas drole du tout .
2) si le createur d'un soft ne le met pas a 1.0.0 , il a en general de bonnes raisons.
[^] # Re: Ben ...
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Ben ...
Posté par jerome (site web personnel) . Évalué à 2.
Sinon, rien ne vaut le test. À priori, il n'y a pas de raison pour que CoLinux soit plus mauvaise qu'une autre, c'est pas difficile à vérifier, fais le test en conditions réelles.
En même temps, le fait de fonctionner avec une machine «serveur» de fichier apporte son lot de nouvelles faiblesses liées au «réseau».
Allez, rien ne vaut un bon petit test.
(N'empêche, c'est goret, 600000 fichiers, faut pas être avare sur les inodes. Après on crache sur maildir :)
[^] # Re: Ben ...
Posté par jerome (site web personnel) . Évalué à 2.
Bon, c'est quand même bancal :)
[^] # Re: Ben ...
Posté par Gniarf . Évalué à 3.
la version n+1 est a priori plus récente que la version n.
voilà. c'est tout. rien d'autre de concret.
un numéro de version, c'est un nom, une étiquette, un repère dans le temps. il y a effectivement des conventions comme nommer en 0.x un logiciel en cours d'écriture, mais il suffit d'aller voir chez Mandrake pour constater de grandioses Beta 5 de Preview 2 de Release Candidate 1 de Mandrake 42.12 Community (PPC) (ce n'est pas une critique, c'est effectivement lourdingue à nommer. communiquer plutot sur des numéros de builds à la Microsoft pour les betas n'est peut être pas totalement idiot et pousserait plus de monde à ne pas attendre la version 2 d'une beta de peur que la première soit "trop beta"...)
pour connaitre le projet en question, je sais que l'auteur n'a pas une "version 1.0" en tête. il ne sait pas ce qu'il y aurait dedans, il ne sait donc même pas ce que ça veut dire. ça n'indique en rien si le projet en question est utilisable ou pas, stable ou pas, remplit tes besoins ou pas.
pourquoi la version actuelle est 0.6.2 et pas 1.0.0 ? parce que la précédente était 0.6.1 :)
[^] # Re: Ben ...
Posté par kesako . Évalué à 2.
On parle ici de mise en PRODUCTION avec une utilisation AUX LIMITES.
puisqu'on ne sait rien sur la stabilité, on ne l'utilise pas. trop dangeureux
[^] # Re: Ben ...
Posté par Gniarf . Évalué à 3.
d'ici une heure je peux ajouter un readme de 3 lignes en français, baptiser ma release coLinuxFR 1.0 et ça ne changera rien à la stabilité de l'engin.
[^] # Re: Ben ...
Posté par Fabimaru (site web personnel) . Évalué à 2.
Je sais que ma solution n'aurait pas été adopté, par contre j'aurais bien vu un vrai Linux avec Samba.
# stabilité et autres infos techniques
Posté par Gniarf . Évalué à 5.
et elle survit très bien. j'estime qu'on peut dire que la stabilité et la survie du système sous coLinux dépend de celle de Windows. moi et d'autres personnes ont cité des uptime de trois jours et plus, et les arretent pour en faire des sauvegardes (un bete fichier) ou pour jouer sous Windows... d'autres ont cité des uptimes bien plus longs (utilisation "serveur") mais je n'ai pas de chiffres dessus.
je n'ai pas utilisé ReiserFS avec, uniquement ext3fs. j'alloue en général 128 Mo au sous-système colinux, mais j'utilise des clients X divers et VNC par exemple, on peut se contenter de 64 une fois l'installation terminée. l'utilisation d'un fichier de swap à coté est possible.
en terme de performances, le système de cache disque de Windows fait qu'une partie de l'image du filesystem sera cachée en RAM et qu'on aura de très bonnes surprises à ce niveau. affecter une priorité basse (au sens Windows) au coLinux suffira à laisser de bonnes performances aux applications Windows en toutes circonstances.
au niveau réseau, outre qu'il est pas forcément facile à configurer du coté Windows pour des gens qui n'y connaissent rien, en particulier pour un réseau local, il pourra constituer le goulet d'étranglement en terme de performances. les gens râlent à ce sujet sur les mailing lists, à relativiser avec les besoins qu'on a, bien sûr. un wget sur un serveur web sur la même machine (coté windows) me donne dans les 500 kb/s, de tête. donc loin d'une vraie carte réseau.
sur un système FAT32, les fichiers des filesystem coLinux sont limités à 4 Go, sur du NTFS, il n'y a pas cette limitation, il y a des images de 10 Go.
concernant le thread à coté ("numéro de version inférieur à 1.0 donc pas en production"), pas grand chose à dire de plus : utiliser une machine de test se rapprochant le plus possible de la machine de production, et tester dessus en abusant de la pauvre bête comme le dernier des gorets. parce qu'indépendement de coLinux, on peut avoir tout plein de choses à coté qui peuvent faire flancher l'ensemble, dont certains utilitaires systèmes chatouilleux, ou des gags comme le SP2 de Windows XP.
outre les versions "officielles" de coLinux qu'on peut trouver sur la page du site sur SourceForge, il y a aussi des snapshots "officieux" dont certains sont "parfaits" (rien à signaler dessus) et d'autres moins (des gens se plaignent de X ou Y dessus sur les mailing lists). j'utilise un snapshoot 0622 depuis des mois et j'en suis ravi.
bref. suivant le niveau de criticabilité du système, ça peut être envisageable. les performances réseaux peuvent être décevantes, ou pas. et avoir le nom d'une solution ne dispensera pas des efforts potentiellement laborieux pour la mettre en oeuvre si on choisit de la tester.
# Colinux + samba
Posté par netchaiev . Évalué à 1.
si colinux flanche , tes fichiers restes là
2) tu peux utiliser tous dans colinux sans oublier de faire une sauv
de l'image(au minimum toutes les nuits) [en principe ton serveur doit déjà avoir un system de sauv,de répli ... ]
Tout dépend de la dispo/importance de ces fichiers
Ps : Expérience (personelle & non professionnelle) je teste depuis quelques temps colinux --> Aucun soucis ....
[^] # Re: Colinux + samba
Posté par netchaiev . Évalué à 1.
pour le 1) -> à oublier
pour le 2) -> je pensais biensur à un éventuel portage de ton appli windows sous wine ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.