Il faudrait que j'engage la discussion avec l'auteur du projet. Je suis pas hostile à l'idée mais ça risque de pas être si simple.
J'ai "forké" principalement pour bricoler dans mon coin sans rien devoir à personne au début. Je n'avais jamais fait de gros projet de développement avant, donc j'étais pas du tout sûr d'arriver à mes fins.
Il y a des raisons techniques aussi, je pensais juste avoir à remplacer les requêtes SQL vers CQL mais au fur et à mesure je me suis rendu compte que ça ne marche pas. S3QL a des caches très agressifs y compris en écriture, certaines données ne sont synchronisées vers le stockage objet que toutes les 24 heures ou au démontage, ce qui évidemment ne peut pas se faire quand plusieurs serveurs accèdent aux données.
Dans certains cas on risque des fichiers corrompus si on a deux écritures simultanément, et j'ai même rencontré un cas où une requête en lecture provoquait la création d'un bloc vide rendant le fichier illisible sur l'un des serveurs (heureusement la modif restait locale, sinon ça aurait effacé le fichier concerné pour tout le cluster).
Et il y a encore pas mal de boulot, j'ai trouvé un bug important quelques heures après avoir posté ce journal.
Il faut aussi noter que S3QL est considéré comme stable depuis un moment, intégrer des gros changements va remettre ça en cause pendant des mois, voire des années sur un projet sensible comme un système de fichiers.
[^] # Re: Pourquoi forker ?
Posté par LoupSolitaire . En réponse au journal CFS : Système de fichiers sur stockage objet. Évalué à 8.
Il faudrait que j'engage la discussion avec l'auteur du projet. Je suis pas hostile à l'idée mais ça risque de pas être si simple.
J'ai "forké" principalement pour bricoler dans mon coin sans rien devoir à personne au début. Je n'avais jamais fait de gros projet de développement avant, donc j'étais pas du tout sûr d'arriver à mes fins.
Il y a des raisons techniques aussi, je pensais juste avoir à remplacer les requêtes SQL vers CQL mais au fur et à mesure je me suis rendu compte que ça ne marche pas. S3QL a des caches très agressifs y compris en écriture, certaines données ne sont synchronisées vers le stockage objet que toutes les 24 heures ou au démontage, ce qui évidemment ne peut pas se faire quand plusieurs serveurs accèdent aux données.
Dans certains cas on risque des fichiers corrompus si on a deux écritures simultanément, et j'ai même rencontré un cas où une requête en lecture provoquait la création d'un bloc vide rendant le fichier illisible sur l'un des serveurs (heureusement la modif restait locale, sinon ça aurait effacé le fichier concerné pour tout le cluster).
Et il y a encore pas mal de boulot, j'ai trouvé un bug important quelques heures après avoir posté ce journal.
Il faut aussi noter que S3QL est considéré comme stable depuis un moment, intégrer des gros changements va remettre ça en cause pendant des mois, voire des années sur un projet sensible comme un système de fichiers.