vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2019-02-27T23:01:10+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3752Utiliser une version fixe de Web2py2019-02-27T23:01:10+01:00Mikaël SalsonUtiliser une version fixe de Web2pyNous utilisons, à la fois pour nos tests et pour nos serveurs de prod, les dernières versions des **sources** de Web2py disponibles (pas les dernières releases). Rien ne garantit donc le bon fonctionnement de ces packages comme l'illustr...Nous utilisons, à la fois pour nos tests et pour nos serveurs de prod, les dernières versions des **sources** de Web2py disponibles (pas les dernières releases). Rien ne garantit donc le bon fonctionnement de ces packages comme l'illustre #3751.
Ne devrait-on pas plutôt fixer la version de Web2py utilisée ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3554bouton dans l'interface pour relancer le swheduler web2py2021-03-05T15:51:00+01:00Thonier Florianbouton dans l'interface pour relancer le swheduler web2pyUne petite question dont je ne suis pas certain de la pertinence: serait-il envisageable de rajouter un bouton pour relancer automatiquement la commande qui relance le scheduler ?
Techniquement, je présume que ce n'est pas si compliqué...Une petite question dont je ne suis pas certain de la pertinence: serait-il envisageable de rajouter un bouton pour relancer automatiquement la commande qui relance le scheduler ?
Techniquement, je présume que ce n'est pas si compliqué que ça. Cependant, ça risque de pérenniser un problème dont on ne connaît toujours pas l'origine (il me semble).
@magiraud @mikael\-s @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3178Ajout de samples : « specific set » est peu clair2018-04-17T14:58:48+02:00Mikaël SalsonAjout de samples : « specific set » est peu clairOn ne sait pas bien à quoi se rapporte le champ « specific set ».
Être plus clair : « Associated patient/run/set » ?
De même il y a le champ « Common set », à remplacer par « Common patient/run/set » ?On ne sait pas bien à quoi se rapporte le champ « specific set ».
Être plus clair : « Associated patient/run/set » ?
De même il y a le champ « Common set », à remplacer par « Common patient/run/set » ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3063conserver le path lors du chargement de plusieurs fichiers2018-03-05T16:54:28+01:00Thonier Florianconserver le path lors du chargement de plusieurs fichiersAurélie qui semble utiliser le chargement directement depuis le serveur ne conserve pas le chemin relatif précédent à ses anciens chargements. Plus précisément, lors du chargement de chaque fichier, elle doit dérouler l'ensemble de son a...Aurélie qui semble utiliser le chargement directement depuis le serveur ne conserve pas le chemin relatif précédent à ses anciens chargements. Plus précisément, lors du chargement de chaque fichier, elle doit dérouler l'ensemble de son arborescence pour retrouver le nouveau fichier à uploader (à priori 7 sous-dossiers a traverser).
Je ne sais pas quelle serait la meilleur solution.
* On peut conserver dans la session le chemin relative au chargement précédent et le précharger dans le `jstree` ?
* Autre point, si on connaît le dossier à partir duquel tous les fichiers sont chargés, on peut modifier le point de montage par défaut pour qu'il pointe dessus, mais pour ça il faut que tous les fichiers a charger proviennent de ce dossier.
cc @RyanHerb @mikael-s @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2609ajouter information sur les patients ouvert par un utilisateur dans la database2022-06-21T14:05:14+02:00Thonier Florianajouter information sur les patients ouvert par un utilisateur dans la databasePour faire suite aux remarques en #2605, # 2606 et #2607, voici mes petites réflexions initiales :
Il faut pour pouvoir effectuer ces tâches que l’information soit présente dans la base de données.
En y réfléchissant un peu plus, je p...Pour faire suite aux remarques en #2605, # 2606 et #2607, voici mes petites réflexions initiales :
Il faut pour pouvoir effectuer ces tâches que l’information soit présente dans la base de données.
En y réfléchissant un peu plus, je pense que le mieux serait d’avoir l' information pour chaque utilisateur et non pas sur les fichiers, comme ça même si plusieurs membres d'une équipe consulte le même patient (par exemple le tech qui lance le run et vérifie son bon déroulement, et le praticien qui consulte les résultat pour les interpréter) ne se croiserait pas.
Il faut donc que lorsqu'un job se met en attente, tourne ou se termine, il mette à jours ses entrée pour l'ensemble des membre du groupe dans le DB.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2536Faut-il maintenir un groupe vide2017-06-15T14:58:37+02:00Thonier FlorianFaut-il maintenir un groupe videVoilà le situation actuelle :
Un hôpital à 2 groupes, ingénieurs (avec l'ensemble des droits) et techniciens (sans le droits de sauvegarder les analyses)
Le premier comporte plusieurs membres, le second un seul.
On me demande de donne...Voilà le situation actuelle :
Un hôpital à 2 groupes, ingénieurs (avec l'ensemble des droits) et techniciens (sans le droits de sauvegarder les analyses)
Le premier comporte plusieurs membres, le second un seul.
On me demande de donner tous les droits à ce dernier membre. La question est donc de savoir si il vaut mieux que je déplace ce membre dans le groupe ingé qui ont tous les droits, et laisser un groupe vide derrière moi, ou bien de donner le droit manquant à ce second groupe, mais poser des soucis si un nouveau membre s'y rajoute.
Perso, je penche pour la première option. Vous êtes d'accord ?
@mikael-s @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2439Diminuer les heartbeats sur la BDD2024-02-06T12:00:08+01:00Mikaël SalsonDiminuer les heartbeats sur la BDDDans #1985 nous avions vu que de nombreuses requêtes étaient exécutées par Web2py pour vérifier si de nouvelles tâches étaient arrivées dans la file d'attente. On avait diminué l'intervalle de vérification pour alléger la pression sur la...Dans #1985 nous avions vu que de nombreuses requêtes étaient exécutées par Web2py pour vérifier si de nouvelles tâches étaient arrivées dans la file d'attente. On avait diminué l'intervalle de vérification pour alléger la pression sur la base de données.
Le [manuel de Web2py](http://web2py.com/books/default/chapter/29/04/the-core#queue_task-) dit ceci :
> Since version 2.4.1 if you pass an additional parameter immediate=True it will force the main worker to reassign tasks. Until 2.4.1, the worker checks for new tasks every 5 cycles (so, 5*heartbeats seconds). If you had an app that needed to check frequently for new tasks, to get a snappy behaviour you were forced to lower the heartbeat parameter, putting the db under pressure for no reason. With immediate=True you can force the check for new tasks: it will happen at most as heartbeat seconds are passed
N'aurait-on pas intérêt à mettre `immediate=True` pour toutes nos tâches ? Il n'y a pas un nombre tel de jobs que cela justifie d'interroger la base de données toutes les 2 ou 3 secondes. Ça aura en plus l'intérêt d'avoir des tâches plus rapidement assignées pour nos utilisateurs ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2131Des workers meurent silencieusement2022-06-20T15:04:27+02:00Mikaël SalsonDes workers meurent silencieusementSur vda nous n'avons que deux workers en ce moment au lieu des 4 paramétrés. Qu'est-ce qui explique ces pertes ? Les workers ne sont pas supposés se relancer à leur décès ?
cc @magiraud @RyanHerbSur vda nous n'avons que deux workers en ce moment au lieu des 4 paramétrés. Qu'est-ce qui explique ces pertes ? Les workers ne sont pas supposés se relancer à leur décès ?
cc @magiraud @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2063Export/import d'un patient/run/sample_set ou d'un ensemble de samples2017-10-27T12:44:24+02:00Thonier FlorianExport/import d'un patient/run/sample_set ou d'un ensemble de samplesEvoqué à Rennes :
Possibilité d'envoyer/partager un patient entre deux hopitaux.
Cas pratique :
Mr Durand est aujourd'hui traité à Lille.
Demain, il prévoit de déménager à Paris.
Les cliniciens de Paris pourront-il recupere...Evoqué à Rennes :
Possibilité d'envoyer/partager un patient entre deux hopitaux.
Cas pratique :
Mr Durand est aujourd'hui traité à Lille.
Demain, il prévoit de déménager à Paris.
Les cliniciens de Paris pourront-il recuperer les données généré à Lille pour poursuivre son analyse ? (hormis de possible questions de droits)
Concretement :
Faut-il leur dire de s'échanger les données fastq et de recréér un "patient" dasn la nouvelle structure ?
Faire un export de l'objet "patient" et de tous ce qui lui est associé, avec un protocole d'import de l'autre coté ? On peux ainsi conserver les notes et rapports déjà édités.
Comment le faire aujourd'hui avec l'approche centralisé ? Un changement de droits dans la base de données suffit ?
@magiraud @mikael-s @RyanHerbprod-server-lilRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2011Ne pas lancer fuse quand le nombre de samples est trop important ?2017-05-22T17:09:00+02:00Vidjil TeamNe pas lancer fuse quand le nombre de samples est trop important ?Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : u...Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : un fuse sur 100 fichiers prend du temps).
De plus le fuse est lancé autant de fois qu'il appartient à de sample sets (donc au moins 2, non ?).
***
753e78c : On ne garde que les 16 premiers. C'est peut-être un peu brutal de faire cela au niveau de fuse.py, mais bon, cela renvoie tout de même un .vidjil pour une visualisation sur les premiers échantillons.
***
Ça me paraît un peu rapide. On n'a pas vraiment de solution pour « degrade gracefully ».
Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers ? Comment on fait pour avoir les autres ? Le custom fuse ne permet pas de sauvegarder les analyses.
Côté serveur il faudrait avertir les utilisateurs qu'ils ne verront que 16 fichiers.
Il y a des utilisateurs avec plus de 16 fichiers, et ça peut faire sens : http://rbx.vidjil.org/browser/index.html?patient=790&config=25
Le problème est surtout avec les runs ou avec Kiel qui met plein d'échantillons différents dans un même patient. Les clones n'ont rien à voir d'un échantillon à l'autre et donc on se retrouve avec des dizaines de milliers de clones dans le fichier. Une autre solution peut être de réduire le top lorsque le nombre de fichier augmente.
***
D'autant plus que l'utilisateur qui nous pause problème à ce sujet n'utilise pas le fuse automatique mais plutôt le custom_fuse, non ? Ne pourrait-ton pas simplement avoir des configs qui fusent et d'autres non ?
***
Oui, effectivement ça serait une solution simple de proposer à Kiel une config sans fuse (on sait faire ça ?).
***
Je pense qu'il y a un bout de code à changer pour que le run accepte de ne pas fuse, mais oui je pense que c'est possible.
***
Oui, le coup de la config en plus, pourquoi pas !
Ou même... la config par défaut pourrit faire 16 fichiers au plus, et on a une config spéciale si quelques gens veulent avoir beaucoup de points.
> « degrade gracefully ».
> Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers
C'est une bonne question. Mais que cela soit oui ou non, c'est un "degrade gracefully" si on montre 16 points... et si on dit qu'on a une autre config si vraiment on veut avoir d'autre chose.
Enfin, quitte à avoir une autre config, on pourrait aussi régler plus finement les paramètres du fuse (top et autres).
***
Ça me semble plus simple de demander à Kiel d'utiliser une config sans fuse, plutôt que de mettre en place le nécessaire pour avertir les utilisateurs que quand il y a plus de X fichiers ils ne verront pas tous les résultats et qu'ils doivent lancer avec une autre config (en espérant qu'il y ait une config correspondante avec un fuse infini).
Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant), j'ai envie de savoir si j'ai de la conta entre mes 20 fichiers pas entre 16 fichiers plus ou moins choisis aléatoirement (dont l'ordre dépendra de l'upload).
En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante (et même pas besoin de demander à Kiel d'utiliser une autre config, on peut mais ça n'est pas indispensable).
***
> plutôt que de mettre en place le nécessaire pour avertir les utilisateurs
Je ne suis pas d'accord sur ce point, c'est très simple avec les notifications. Cela permet d'avoir, par défaut, un comportement correct pour la majorité des utilisateurs, et de les inciter à utiliser correctement les patients. (Et s'ils leur manquent quelque chose, c'est facile de rajouter une config pour un user, pour des bonnes raisons). Je préfère être sûr, dès maintenant, que tous les utilisateurs font ce qu'il faut (et traiter au cas par cas quelques cas comme Kiel) plutôt que de retomber dans quelques mois sur un autre utilisateur qui fera pareil.
> Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant)
Oui, tout à fait ! 16 est un exemple, cela peut être 32 ou 42 :-) Dans tous les cas, au-delà de 8-10 simples, on devrait cacher sur le graphe (cf une autre tâche). Et encore plus si on fait des SampleSets : peut-être que quelqu'un aura un SampleSet de 100/200 patients correspondant à un truc particulier... (Mais lance-t-on les mêmes configs dans tous les SampleSet ? Ce n'est pas obligé.)
> En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante
Oui, c'est aussi possible, par exemple (1000 / #samples)... mais on a déjà du mal à expliquer ce qu'est notre top, alors là cela va être encore plus dur. Ou alors, 1000 tant que #samples < 8, puis ensuite cela descend.
***
Par défaut, met-on le -f dans fuse.py à 0 et on fait une config pour Kiel où le -f est à 1 (ou X) ?
***
Kiel vient d'ajouter une centaine de fichiers → –10 Go
***
@magiraud @RyanHerb @mikael-sWeb 2017.05Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1950Trouver une autre méthode de scheduling, indépendante de web2py2022-06-20T11:59:42+02:00Vidjil TeamTrouver une autre méthode de scheduling, indépendante de web2py(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (gr...(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (groupes de) workers à certaines tâches
2) ou 3) permettrait de lancer des choses annexes et rapides (type FineSegmenter ou compare patients ou ...) même si des gros Vidjil (ou autres) tournent
Enfin, penser tout cela dans le cadre d'un "noeud de calcul", possiblement indépendant du serveur web. Le serveur de calcul ne reçoit que des lignes de commande à exécuter et à accès aux fichiers nécessaires par un montage.
Rien d'urgent, à réfléchir posément dans les prochains mois.
***
Task spooler: http://vicerveza.homeunix.net/~viric/soft/ts/ présente les fonctionnalités majeures que nous cherchons (tâches interdépendantes, changement d'ordre dans la file, etc), mais n'a pas d'API pour s'en servir en réseau.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1588Récupérer des données par FTP/HTTP/NFS ou autre2017-11-22T12:48:32+01:00Vidjil TeamRécupérer des données par FTP/HTTP/NFS ou autreLe serveur doit pouvoir récupérer des fichiers à distance (par FTP/HTTP). La première étape est d'avoir un contrôleur qui permet ça (pour que des scripts puissent y accéder au moins). Ensuite on pourrait l'exposer dans l'interface (file/...Le serveur doit pouvoir récupérer des fichiers à distance (par FTP/HTTP). La première étape est d'avoir un contrôleur qui permet ça (pour que des scripts puissent y accéder au moins). Ensuite on pourrait l'exposer dans l'interface (file/edit_form).
***
Marc avait l'air motivé, merci :)
***
Et on peut avoir deux versions : une qui récupère le fichier à l'URL donnée et l'autre qui ne stocke que l'URL.
Ensuite Vidjil sera lancé directement avec l'URL : ça marche déjà en utilisant la puissance de bash (sh ?) :
./vidjil -e all -G germline/IGH <(wget -O - -q http://www.vidjil.org/seqs/Stanford_S22.fasta)
(le -e all est là pour éviter l'estimation du nombre de reads)
***
Discuté à l'instant : pour que l'e-value fonctionne, on pourrait
- soit wrapper dans un scipt shell pour vraiment avoir le fichier
- soit avoir un nb de reads par défaut (1 milllion)
- soit estimer ce nb de reads de l'extérieur (taille du fichier), et le passer en ligne de commande
L'estimation peut être à la louche, à un facteur 10 ou 100 près :)
***
@DuezWeb 2017.03Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1448Séparation serveurs : app (html/js) // vda2017-11-22T12:48:32+01:00Vidjil TeamSéparation serveurs : app (html/js) // vdaFaudrait-il séparer (physiquement, virtuellement) les serveurs ?
- un qui ne fait que la db + browser
- un autre pour upload / vidjil, qui peut éventuellement ramer, mais qui ne bloque pas l'interaction des users avec la db et le b...Faudrait-il séparer (physiquement, virtuellement) les serveurs ?
- un qui ne fait que la db + browser
- un autre pour upload / vidjil, qui peut éventuellement ramer, mais qui ne bloque pas l'interaction des users avec la db et le browser
Juste une réflexion, on ne va pas se lancer là-dedans pour l'instant ! Et en plus, en production, ce n'est même pas dit que nos pb d'efficacité soient si importants, typiquement dans un hôpital il y aura 1 ou 2 utilisateurs, pas 100 simultanés :)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1359export html: transformation en .pdf par le serveur2022-06-20T10:10:27+02:00Vidjil Teamexport html: transformation en .pdf par le serveurPriorité basse, à voir même si c'est utile
***
@nobodyPriorité basse, à voir même si c'est utile
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2141Donner accès aux fichiers produit par les logiciels RepSeq utilisés par Vidjil2017-05-22T18:24:36+02:00Mikaël SalsonDonner accès aux fichiers produit par les logiciels RepSeq utilisés par VidjilDiscuté avec @magiraud et @RyanHerb : on veut pouvoir donner accès aux différents fichiers produits par les softs que nous lançons (c'est-à-dire pour l'instant Vidjil et MiXCR). Il n'y a a priori rien à cacher dans ces fichiers.Discuté avec @magiraud et @RyanHerb : on veut pouvoir donner accès aux différents fichiers produits par les softs que nous lançons (c'est-à-dire pour l'instant Vidjil et MiXCR). Il n'y a a priori rien à cacher dans ces fichiers.Web 2017.05Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2032Modifier le contrôleur du segmenteur pour permettre l'interaction avec la pag...2017-04-12T14:07:43+02:00Vidjil TeamModifier le contrôleur du segmenteur pour permettre l'interaction avec la page d'ArmandDiscussion avec @RyanHerb et @Tydax
La page d'accueil est statique, pas besoin de passer par un contrôleur. En revanche, l'envoi des séquences doit faire appel en AJAX au contrôleur qui nous renvoie un JSON qu'on peut donner à manger au...Discussion avec @RyanHerb et @Tydax
La page d'accueil est statique, pas besoin de passer par un contrôleur. En revanche, l'envoi des séquences doit faire appel en AJAX au contrôleur qui nous renvoie un JSON qu'on peut donner à manger au modèle, via parseJsonData.
Il faut donc modifier le contrôleur : c'est lui qui gérait le formulaire, c'est inutile maintenant et renvoyer un JSON.
Poke @magiraud
***
@magiraud @RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2007Empêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espac...2020-01-08T17:39:47+01:00Vidjil TeamEmpêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espace disqueOn sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on...On sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on ne se retrouve jamais avec un disque plein et pas avec des jobs en failed parce qu'il n'y a plus d'espace disque.
Par contre, prévoir de spammer les admins dès que la limite est atteinte pour qu'ils fassent quelque chose (en générant un ticket web2py ?)
***
C'est en prod. On a une limite en pourcentage qui se fixe dans defs.py. Actuellement réglé sur 1%. La limite est commune pour toutes les partitions mais la vérification est spécifique (donc il peut s'avérer que l'upload soit bloqué, mais pas les runs
***
Merci Ryan.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1920Retour à l'utilisateur lorsque la requête prend un peu de temps2017-11-24T11:05:20+01:00Vidjil TeamRetour à l'utilisateur lorsque la requête prend un peu de tempsÀ partir de quelques dixièmes de seconde, afficher « Loading » en haut de la page, puis au bout de une seconde « Still loading » avec un fond un peu plus voyant. Cela ne changera rien aux timeouts, mais cela devrait éviter que les utilis...À partir de quelques dixièmes de seconde, afficher « Loading » en haut de la page, puis au bout de une seconde « Still loading » avec un fond un peu plus voyant. Cela ne changera rien aux timeouts, mais cela devrait éviter que les utilisateurs appuient de nombreuses fois sur le bouton (en pensant que la requête n'a pas été prise en compte), surchargeant encore plus le serveur.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1919Multi-threader web2py2017-03-22T17:36:24+01:00Vidjil TeamMulti-threader web2pyApparemment web2py par défaut devrait être multi-threadé, voir pourquoi il ne l'est pas. Cela pourrait résoudre pas mal de timeouts.
***
Tiens, on apprend des choses au redémarrage de web2py :
*** Python threads support is disabled. You...Apparemment web2py par défaut devrait être multi-threadé, voir pourquoi il ne l'est pas. Cela pourrait résoudre pas mal de timeouts.
***
Tiens, on apprend des choses au redémarrage de web2py :
*** Python threads support is disabled. You can enable it with --enable-threads ***
***
Après vérification, nous avons 4 processus web2py qui tournent. D'après ce post: https://groups.google.com/forum/#!topic/web2py/mPdn1ClxLTI c'est tout à fait ce qu'il faut avoir.
Les requêtes sont encore bloquantes.
Activer le flag enable-threads n'a rien changé sur mon environnement.
***
@RyanHerbWeb 2017.03https://gitlab.inria.fr/vidjil/vidjil/-/issues/1653Incohérence taille totale des fichiers2016-11-29T14:39:03+01:00Vidjil TeamIncohérence taille totale des fichierssur la liste des patients, en bas à droite, 282 GB.
Mais 455G dans /mnt/upload.
***
Au passage, vérifié sur *un* patient, les tailles correspondent entre ce qui est affiché et ce qui est sur le disque (environ, à un facteur 1.024^x près)...sur la liste des patients, en bas à droite, 282 GB.
Mais 455G dans /mnt/upload.
***
Au passage, vérifié sur *un* patient, les tailles correspondent entre ce qui est affiché et ce qui est sur le disque (environ, à un facteur 1.024^x près)
***
Les fichiers non référencés dans la DB (165 GB) ont été déplacés dans /mnt/uploads/upload-trash, on les garde en talisman ?
/mnt/uploads/upload : 290 GB
liste des patients : 282 GB
***
@magiraud @mikael-s