[1fichier] "Montez" votre stockage 1fichier en une commande simple !

Zakhar · Le 06/03/2022, à 22:51

bobo15995 a écrit :

En effet, un abonnement sur 1fichier sera mieux que de prendre un abonnement pour un VPN (plus cher en plus)...

Surtout qu'un abonnement VPN n'est pas la panacée... tu ne fais que déplacer la "confiance" de ton FAI (Fournisseur d'Accès à Internet) à ton fournisseur de VPN !..

Certains ont été surpris désagréablement... car les fournisseurs de VPN ne sont pas non plus au dessus des lois, même si ce ne sont pas les lois de la France.

Pour les choses "confidentielles" rien ne vaut TOR, en plus c'est gratuit !.. Bien sûr tu ne peux pas y faire certaines choses de façon simple car ça ne supporte pas certains protocoles majeurs comme UDP.

Zakhar · Le 18/03/2022, à 07:29

bobo15995 a écrit :

Merci pour cette réponse plus que complète !
En effet, j'ai partagé mon compte avec un autre membre de mon foyer. Il n'a pas la même IP. Mais bon... comme il s'agit de quelqu'un de mon foyer, je trouve ça vraiment exagéré de ne pas pouvoir lui partager l'accès.
C'est sur qu'après ça serait très compliqué pour 1fichier d'éviter les abus.
Je ne sais pas encore quoi faire. Entre écrire à 1fichier, utiliser un proxy/VPN ou simplement abandonner l'idée de partager mon compte.

Une petite news pour toi @bobo15995

https://www.nextinpact.com/lebrief/6865 … urs-foyers

Tu vois, il n'y a pas que 1fichier.com, même chez Netflix le "partage de codes" en dehors d'un domicile unique va devenir plus difficile (payant !)

Dernière modification par Zakhar (Le 19/03/2022, à 07:18)

Zakhar · Le 10/04/2022, à 15:04

(10 Avril 2022) Version 1.9.0

La dernière version (1.8.4) datait maintenant de plus d'un an. Le développement n'est pas arrêté, bien au contraire, on a un tout nouveau tout beau "moteur de lecture".

Nouveautés par rapport à la 1.8.4

Nouveau : moteur de lecture tout nouveau (voir plus bas).
Optimisation: les statistiques ont évolué avec le nouveau moteur de lecture, et lorsque vous ne les utilisez pas, les appels sont "bouchonnés" pour ne pas perdre de temps.
Nouveau : option --threads pour régler le nombre de threads à une valeur différente de celle choisie automatiquement par le programme.

Évolution majeure
L'évolution ne concerne que la partie lecture, l'écriture est inchangée.
Le "moteur de lecture" a été complètement ré-écrit "from scratch". L'ancien était in-maintenable et comportait des bugs connus heureusement assez rares (race conditions).
Le nouvel algorithme de lecture :

Passage à 64 streams (en 64 bits) sur un nombre de threads variable (et configurable) au lieu de 4 threads avec 1 stream !
Optimisations de nouveaux patterns de lecture (à la "download accelerator")
Meilleure gestion des lectures en désordre qui fait gagner du temps en évitant les sous-requêtes au serveur.
Code plus générique, plus clair, sans lock (sémaphores uniquement).
Davantage d'options de build (debug, no stats)
Le package standard est construit sans debug et avec statistiques. Néanmoins, si vous ne les activez pas, les statistiques ne sont désormais plus calculées, ce qui évite de consommer des ressources !..

Raspberry Pi OS -ex Raspbian- (Raspbian Buster 32 bits): 1fichierfs_1.9.0~buster-1_armhf.deb

$ stat -c "%s %n" 1fichierfs_1.9.0~buster-1_armhf.deb; sha256sum 1fichierfs_1.9.0~buster-1_armhf.deb; md5sum 1fichierfs_1.9.0~buster-1_armhf.deb
95552 1fichierfs_1.9.0~buster-1_armhf.deb
410204f3fd6e162a80c6e4f4903081f12ca8da38f839e3f757777c45c038845b  1fichierfs_1.9.0~buster-1_armhf.deb
a7f43f907726cf59aea934addd283923  1fichierfs_1.9.0~buster-1_armhf.deb

Dernière modification par Zakhar (Le 10/04/2022, à 15:23)

Jarodd · Le 10/04/2022, à 16:35

Un énorme merci à toi !

Dernière modification par Jarodd (Le 10/04/2022, à 16:35)

Zakhar · Le 10/04/2022, à 17:10

Jarodd a écrit :

Un énorme merci à toi !

De rien.

N'hésitez pas à rapporter si vous voyez des bugs. Ça fait bien deux mois que ça tourne chez moi... mais on sait jamais.

Zakhar · Le 01/05/2022, à 10:14

À l'occasion du "backport" vers astreamfs, j'ai corrigé deux bugs dans le "moteur" de lecture.
- Un crash
- Un écrasement mémoire dans les statistiques

Cela se produit bien sûr uniquement dans certaines situations bien spécifiques, le deuxième bug ne se produisant pas si vous n'utilisez pas les statistiques.

Je fais tourner quelque temps sur mes PCs, et je ferai un nouveau package 1.9.1 si je ne vois pas d'autre anomalie.

J'en profiterai pour rajouter sur le launchpad le packaging 22.04 puisqu'elle est désormais "release".

Si d'ici là vous pensez être affecté par un des deux bugs, vous pouvez toujours compiler à partir du Gitlab qui est à jour de ces deux corrections.

Bon 1er mai à toutes et tous.

Dernière modification par Zakhar (Le 01/05/2022, à 11:37)

NOLAK · Le 05/05/2022, à 09:42

Bonjour Zhakhar,

J'ai régulièrement un problème lors de copie.
Ce message tourne un petit moment ... si je m'en rend compte, je supprime les fichiers dans le dossier .upload.1fichierfs et je remonte le lecteur sinon j'ai le droit à un ban.

INFO: <<< API(in) (iReq:219364) file/mv.cgi POST={"urls":["https://1fichier.com/?xxxxxxxxxxx"],"destination_folder_id":xxxxxxx,"rename":"fichier"} name=(null)
ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/file/mv.cgi` name=`(null)`.
INFO: >>> API(out) (iReq:219364) retry=0 json size=53 hCode=403
WARNING: failed to rename from upload dir using target dir ID xxxxxxx, trying full path: /dossier/dossier/fichier
ERROR: -2, failed to rename with full path: /dossier/dossier/fichier
WARNING: failed with -2 to move `F1899933xx680ebc9_0000058XX` to /xxxxxxx/ `fichier`

Tu as une idée de quoi ça vient ?

Zakhar · Le 05/05/2022, à 10:30

Oui, sans doute d'un logiciel que tu utilises qui crée des répertoires temporaires qui sont ensuite supprimés intentionnellement par l'utilisateur (par exemple sur l'interface web).

Le principe de l'upload est que tous les fichiers sont envoyés vers le répertoire .upload-1fichierfs qui constitue un "stockage temporaire".
On ne peut pas faire autrement, parce qu'imagine que tu copies en parallèle deux fichiers vers des répertoires différent, c'est parfaitement Ok pour un "filesystem" normal.
Seulement, 1fichier.com ne permet qu'un seul répertoire d'upload, et on ne pourrait donc pas traiter ce cas !
Aussi 1fichierfs fait cela à partir d'un "sous-compte FTP" qu'il crée automatiquement, lequel possède ce répertoire cible. Cela permet de ne pas gêner l'utilisateur qui peut toujours paramétrer son propre répertoire d'upload FTP.

Par conséquent tout fichier uploadé est en premier posé dans le répertoire .upload-1fichierfs (créé automatiquement par 1fichierfs à la racine dès que tu fais une copie).
En même temps que cette copie temporaire, 1fichierfs mémorise de façon persistante l'ID du répertoire cible (numéro interne attribué par 1fichier.com à chaque répertoire), et de façon non persistante, le chemin du répertoire.
La différence de "peristence" est que le chemin complet n'est mémorisé que tant que le driver tourne, tandis que l'ID persiste même si tu coupes le driver.

Un fois le cycle d'upload terminé :
- Upload lui-même
- Attente de 5 minutes pour FTP
- Attente de X minutes dépendant de la taille du fichier (contrôles sur le stockage 1fichier.com côté serveur)

... 1fichierfs va réaliser l'opération finale qui consiste à renommer/déplacer le fichier sur .upload-1fichierfs vers le répertoire cible qu'avait précisé l'utilisateur initialement.

En premier lieu 1fichierfs va utiliser l'ID qui a été mémorisé. Cela offre l'avantage de fournir "gratuitement" la fonctionnalité de ne pas se tromper de cible même si des répertoires intermédiaires ont été renommés.
Exemple tu vas :
- Copier foo.txt vers le répertoire /files/bar
- Et pendant ou après la copie (mais avant le renommage/déplacement expliqué plus haut) tu décides de changer le nom du répertoire bar en foobar.

Eh bien ce renommage sera transparent puisque le changement du nom d'un répertoire ne change pas son ID, donc la copie finale par 1fichierfs ira bien vers /files/foobar, comme attendu.

Si la renommage/déplacement par ID échoue... cela signifie nécessairement que le répertoire en question a été intentionnellement effacé par l'utilisateur.
Dans ce cas, et tant que le driver n'a pas été arrêté, il va essayer d'utiliser le chemin complet qui est gardé en mémoire vive pour faire la copie finale. Il semble confirmé par ta "log" qu'effectivement le répertoire cible n'existe plus. Cette partie là est plus lente mais a l'avantage de ne pas provoquer de "403", juste ça échoue si le chemin complet n'existe plus. A noter qu'on ne trace pas les "renommages" car on par du principe que l'ID devrait être bon. Donc ce "fallback" n'est utile que si l'utilisateur a intentionnellement supprimé les répertoires, puis, pris de remords, les a recréés exactement à l'identique. Là on retrouvera alors le chemin complet avec un ID cible qui a changé puisque les ID sont toujours uniques.

Alors là plusieurs choses :
- en principe (mais il peut toujours y avoir des bugs !) si tu n'utilises qu'une seule instance de 1fichierfs pour faire tes copies, elle ne te laissera pas effacer un répertoire qui est la cible d'une copie en cours, car même si le fichier n'est pas encore physiquement dans le répertoire en question, le driver a bien noté ton intention de le copier à cet endroit, et il n'est pas possible de supprimer un répertoire non vide.
- cependant, cela est si tu utilises uniquement une instance unique de 1fichierfs. Bien sûr, si en parallèle tu vas sur l'interface web, le nouveau répertoire qui a été créé apparaît vide pendant un certain temps (le temps du cycle d'upload expliqué plus haut). Donc rien n'empêche de supprimer le répertoire sur l'interface web pendant ce temps là. La suppression peut aussi venir si tu as plusieurs instances de 1fichierfs sur des machines différentes. Les instances ne communiquant pas entre elle, il est possible de supprimer le répertoire cible d'un upload sur instance A à partir de instance B pendant le cycle upload.
- enfin, tâcher d'accéder ou renommer vers un répertoire qui n'appartient pas à l'utilisateur (ou a été supprimé) est compté par 1fichier.com comme une tentative de malversation, c'est à dire comme si tu essayais d'accéder aux répertoires des autres, et le code retour est donc 403. Hélas après un certain nombre de 403 c'est effectivement le ban

Il n'y a malheureusement rien que 1fichierfs puisse faire contre une telle "désynchronisation intentionnelle provoquée par l'utilisateur", c'est à dire si toi (ou quelqu'un qui a accès) réalise des opérations via 1fichierfs et en parallèle supprime un répertoire indispensable sur l'interface web.

La log que tu montres avec la tentative "fallback" sur le nom complet ne peut exister (sauf bug encore !) que si tu as provoqué cette désynchronisation tandis que 1fichierfs tournait.
En effet, si tu l'arrêtes et le redémarres, il va faire la "reprise", mais là il n'a plus les informations sur le chemin complet, seulement les ID des répertoires cibles.

Le bannissement peut aussi se produire à la reprise si tu as des copies vers plusieurs répertoires différents, et que ces répertoires ont été supprimés.
Encore une fois, il n'y a malheureusement rien que 1fichierfs puisse faire contre une désynchronisation qui a été provoquée intentionnellement... et qui malheureusement, si elle est trop répétée, entraîne un "ban" temporaire de 1fichier.

Il est possible que tu n'aies pas conscience de cette désynchro "intentionnelle" parce qu'elle pourrait être provoqué par une autre logiciel, mais sauf bug (encore une fois toujours possible), la chose ne peut venir que de cela.

Dis m'en donc davantage si tu penses que c'est un bug, potentiellement en message privé si tu préfères.

Dernière modification par Zakhar (Le 05/05/2022, à 10:58)

NOLAK · Le 05/05/2022, à 10:59

Merci, tu m’as bien éclairé, j’ai en effet un logiciel qui me supprime les répertoires vides et justement sur une autre instance.
J’utilise Docker et j’ai montés deux répertoires et dans deux container différents, je comprends mieux. Je vais corriger le problème.
Comment je fais pour te contacter en privé, je ne trouve pas les mp sur ce forum ?

Dernière modification par NOLAK (Le 05/05/2022, à 11:56)

Zakhar · Le 05/05/2022, à 12:03

Voila donc l'explication effectivement !

Il faut aussi éviter de supprimer "à la main" les répertoires vides qui se trouvent dans /.upload-1fichierfs car ce sont précisément eux qui permettent la "reprise", c'est-à-dire savoir où renommer/déplacer un fichier si le driver a été arrêté et ensuite redémarré.

De façon plus générale, un problème constant des montages "réseau" est précisément cette désynchronisation qui peut toujours survenir si on fait des manipulations "en parallèle" sur la structure distante.
Travailler en "écriture" (suppression, renommage) de parties communes de l'arbre distant sera toujours périlleux car cela crée un désynchronisation contre laquelle il est difficile de se protéger totalement dans un programme tel 1fichierfs sans afficher des performance déplorable comme par exemple relire tous les répertoires systématiquement depuis le serveur !

Même la relecture systématique des répertoires depuis le serveur ne serait de toute façon pas totalement absolue, pour des questions de non-atomicité.

Dernière modification par Zakhar (Le 05/05/2022, à 12:17)

Zakhar · Le 07/05/2022, à 10:12

NOLAK a écrit :

Comment je fais pour te contacter en privé, je ne trouve pas les mp sur ce forum ?

C'est expliqué ici https://forum.ubuntu-fr.org/viewtopic.php?id=2069333

Mais effectivement, pour éviter les robots à spam, il faut totaliser au minimum 50 posts.

Zakhar · Le 08/05/2022, à 19:56

(8 mai 2022) Version 1.9.1

Nouveautés par rapport à la 1.9.0

Nouveau : package pour Jammy (22.04 LTS).
Fix crash : dans certains enchaînements de lecture, un crash se produisait.
Fix bug: écrasement mémoire possible avec les statistiques activées.

Correction de bugs
Si vous avez installé la 1.9.0, il est prudent de faire la mise à jour. Même si vous n'utilisez pas les statistiques, le premier bug pourrait vous affecter

Raspberry Pi OS -ex Raspbian- (Raspbian Buster 32 bits): 1fichierfs_1.9.1~buster-1_armhf.deb

$ stat -c "%s %n" 1fichierfs_1.9.1~buster-1_armhf.deb; sha256sum 1fichierfs_1.9.1~buster-1_armhf.deb; md5sum 1fichierfs_1.9.1~buster-1_armhf.deb
95924 1fichierfs_1.9.1~buster-1_armhf.deb
0421404eed23878d72e115e1ff61ae528ba98e78e29bd287b5e785c8712a8446  1fichierfs_1.9.1~buster-1_armhf.deb
027f73dcd9d3007206c5b8c83f07ce25  1fichierfs_1.9.1~buster-1_armhf.deb

Dernière modification par Zakhar (Le 08/05/2022, à 20:30)

Zakhar · Le 29/07/2022, à 09:09

Bonjour utilisateurs de 1fichierfs.

Quelque part durant la semaine prochaine, je publierai une version corrective 1.9.2

En effet, il existe un bug qui peut se manifester par un crash ou comportement incohérent, signalé ici : https://gitlab.com/BylonAkila/astreamfs/-/issues/5

J'avais déjà repéré le "bug" l'ayant subi moi-même et la correction est apportée dans le source en ligne.

Un autre crash dans le moteur de lecture a été corrigé, mais celui-ci est fort improbable compte tenu de la façon dont 1fichierfs utilise le "moteur".

Au passage le "moteur" a été amélioré, surtout pour astreamfs, avec la fonction "retry" (on essaye plusieurs fois si on a un incident réseau). Cela n'a cependant pas été implémenté dans 1fichierfs car je n'ai jamais constaté de fonctionnement incorrect des serveurs de 1fichier.com qui nécessiterait des "retry". Si toutefois vous le constatez, merci de m'en faire retour, je peux facilement rajouter "retry" dans les paramètres de lancement.

En attendant, si vous constatez le crash de façon trop récurrente/gênante, vous pouvez récupérer les sources en ligne et faire le "build" par vous-mêmes.

L'évolution future qui est dans les tuyaux est de rendre possible le réglage des "gaps", c'est à dire à quelle distance le moteur considère qu'une lecture appartient au même "stream". Pour l'instant c'est une distance fixe de 512ko (un demi méga) correspondant à 4 blocs de lecture maximale à 128ko. Ce réglage peut aider dans des modes de lecture "pas tout à fait séquentiel", au détriment de davantage de consommation mémoire et/ou "d'over-read".

Zakhar · Le 06/08/2022, à 14:39

(6 août 2022) Version 1.9.2

Nouveautés par rapport à la 1.9.1

Fix crash : un crash théorique pourrait se produire, mais compte tenu de la façon dont 1fichierfs utilise le moteur de lecture, cela devrait être totalement improbable.
Fix crash : un crash se produit dans certains cas à l'ouverture d'un stream à cause d'un oubli d'initialisation. Bug rapporté aussi sur le gitlab.
Amélioration : algorithme plus simple et rapide à l'ouverture d'un stream.
Fonctionnalité non utilisée : le moteur de lecture supporte les reprises (retry). Cela ne me semblant pas nécessaire avec 1fichier.com, la fonctionnalité du moteur n'est pas utilisée par 1fichierfs. Si vous pensez que cela est au contraire nécessaire, merci de faire un rapport.
Documentation : mise à jour du manuel.

Correction de bugs
Compte tenu du deuxième crash corrigé, lequel a aussi été noté par d'autres utilisateurs, je suggère d'accepter la mise à jour !

Raspberry Pi OS -ex Raspbian- (Raspbian Buster 32 bits): 1fichierfs_1.9.2~buster-1_armhf.deb

$ stat -c "%s %n" 1fichierfs_1.9.2~buster-1_armhf.deb; sha256sum 1fichierfs_1.9.2~buster-1_armhf.deb; md5sum 1fichierfs_1.9.2~buster-1_armhf.deb
96348 1fichierfs_1.9.2~buster-1_armhf.deb
cb7ca0433fadf25e0c6b0687b874badc09606a8a25ee785c38ee5888ba47b8a6  1fichierfs_1.9.2~buster-1_armhf.deb
ac7386afcadf8064324c76e5c19e84dd  1fichierfs_1.9.2~buster-1_armhf.deb

Dernière modification par Zakhar (Le 06/08/2022, à 16:49)

grosjean · Le 22/08/2022, à 17:01

Hello,
pour une raison qui m'est inconnue, de temps en temps, 1fichierfs est bloque dans la boucle suivante:
https://gitlab.com/BylonAkila/astreamfs … ker.c#L907

Les dernieres lignes de log en debug:

[1fichierfs  1584.996] DEBUG: [01]... << do_actions(0x7f3779c09c00) = 1
[1fichierfs  1584.996] DEBUG: [01]... >> do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> do_actions(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_actions(0x7f3779c09c00) = 1
[1fichierfs  1584.996] DEBUG: [01]... >> do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> do_actions(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_actions(0x7f3779c09c00) = 1
[1fichierfs  1584.996] DEBUG: [01]... >> do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> do_actions(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_actions(0x7f3779c09c00) = 1
[1fichierfs  1584.996] DEBUG: [01]... >> do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> do_actions(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_actions(0x7f3779c09c00) = 1
[1fichierfs  1584.996] DEBUG: [01]... >> do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... << do_transfers(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]... >> wait_for_actions_or_reads(0x7f3779c09c00)
[1fichierfs  1584.996] DEBUG: [01]...^C

Si tu as une idee, je prends

Dernière modification par Ayral (Le 22/08/2022, à 22:36)

Zakhar · Le 22/08/2022, à 23:07

Bonjour Grosjean, et bravo pour la compilation en mode debug !

Est-ce que tu as bien la version 1.9.2 ?

$ 1fichierfs -V
(...)
1fichierfs: version 1.9.2
(...)

Car ce "bug" (c'était bien un bug) a été signalé sur le Gitlab : https://gitlab.com/BylonAkila/astreamfs/-/issues/5, avec aussi un signalement de boucle là où tu le montres, et l'auteur du rapport #5 ci-dessus confirme que cela ne s'est pas reproduit en 1.9.2 qui est la dernière "committée".

Pour mettre à jour en 1.9.2, il te suffit d'avoir installé le PPA et d'accepter la mise à jour si tu es sous Ubuntu ou un dérivé, sinon prendre le dernier code sur le Gitlab (ce que visiblement tu sais faire !)

Si tu confirmes que cela se reproduit encore en 1.9.2, c'est sans doute un autre bug et il me faut un peu plus que les dernières lignes de debug pour arriver à comprendre pourquoi. Tu peux m'envoyer le fichier debug en MP en l'ayant purgé des noms de fichiers/lrépertoires/liens, par exemple en le stockant sur ton cloud 1fichier et en me partageant un lien (ça ne passe pas par mail, les fichiers "debug" font vite des 100aines de méga voire plusieurs giga en transfert actif).

Dernière modification par Zakhar (Le 22/08/2022, à 23:10)

grosjean · Le 23/08/2022, à 08:05

Hello,
la version:
╭─jenfi@nuc ~/build/astreamfs [master●]
╰─➤./1fichierfs -V
Copyright (C) 2018-2022 Alain Bénédetti
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under the conditions of the GPLv3 or later, at your convenience.
Full license text can be found here: https://www.gnu.org/licenses/gpl-3.0.html

1fichierfs: version 1.9.2
Build option: DEBUG
libcurl/7.84.0 (x86_64-pc-linux-gnu) OpenSSL/1.1.1q
FUSE library version: 2.9.9
fusermount version: 2.9.9
using FUSE kernel interface version 7.19

L'auteur du report, c'est moi en fait
J'ai malheureusement ecrase le fichier, mais devrait pouvoir etre en mesure d'en fournir un autre.

Merci encore, et pour etre honnete, fabuleux project.

grosjean · Le 23/08/2022, à 08:43

En attendant de repeter ce bug, je viens d'avoir un autre crash.
Tu as du recevoir une notification par mail du fichier de log.

La trace:

Reading symbols from ./1fichierfs...
[New LWP 797832]
[New LWP 797878]
[New LWP 797825]
[New LWP 798888]
[New LWP 797827]
[New LWP 798311]
[New LWP 798821]
[New LWP 797830]
[New LWP 797831]
[New LWP 797828]
[New LWP 798312]
[New LWP 798389]
[New LWP 798827]
[New LWP 798703]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
--Type <RET> for more, q to quit, c to continue without paging--
Core was generated by `./1fichierfs /home/jenfi/WORK/1fichier -4 --api-key=@~/.1fichier.key --refresh-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000559a2687b7fe in orig_do_actions (pdata=0x7f01e6ffcc00) at astreamfs_worker.c:2085
2085 for (a = pdata->actions; NULL != a; a = a->next) {
[Current thread is 1 (Thread 0x7f01e6ffd6c0 (LWP 797832))]
(gdb) bt
#0 0x0000559a2687b7fe in orig_do_actions (pdata=0x7f01e6ffcc00) at astreamfs_worker.c:2085
#1 0x0000559a2687204e in do_actions (arg1=0x7f01e6ffcc00) at /home/jenfi/build/astreamfs/astreamfs_worker_dbg.c:694
#2 0x0000559a2687c308 in orig_async_worker (arg=0x7f01ed616ae8) at astreamfs_worker.c:2358
#3 0x0000559a26872588 in async_worker (arg=0x7f01ed616ae8) at /home/jenfi/build/astreamfs/astreamfs_worker_dbg.c:717
#4 0x00007f01edefa78d in ?? () from /usr/lib/libc.so.6
#5 0x00007f01edf7b8e4 in clone () from /usr/lib/libc.so.6
(gdb) print a
$1 = (struct action *) 0x7f065c2b4f34
(gdb) print *pdata
$2 = {fds = {{fd = 10, events = 1, revents = 1}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -15, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -18, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0,
revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -23, events = 0, revents = 1}}, now = 3785227,
last_activity = 3785227, last_clean = 3785226, mfds = 0, n_files = 2, nst = 0, pst = 0, actions = 0x7f01ac3b4d30, owned_streams = 1 '\001',
list = "\377\f\377\377\377\377\377\377\377\377\377\377\023\377\377\377\377\377\377?", '\377' <repeats 43 times>, "@"}
(gdb) print *pdata->actions
$3 = {next = 0x7f065c2b4f34, type = ACTION_CLOSE, sem_done = 0x0, a = {r = {fh = 139645160527504, bufp = 0x400, offset = 139645160570528, size = 0, written = 0, start = 0, idx = 0 '\000', tid = 0 '\000', map = 0 '\000',
retry = 0 '\000'}, g = {buf = 0x7f01ac301690 "\024", offset = 1024, size = 139645160570528, written = 0, retry = 0 '\000'}, c = {fh = 139645160527504}, f = {fh = 139645160527504, tid = 0 '\000'}, t = {start = {
tv_sec = 139645160527504, tv_nsec = 1024}, end = {tv_sec = 139645160570528, tv_nsec = 0}, fh = 0, sh = 0x0, fd = 0, err = 0, idx = 96 '`'}, ss = {start = {tv_sec = 139645160527504, tv_nsec = 1024}, end = {
tv_sec = 139645160570528, tv_nsec = 0}, t_now = 0, fh = 0, written = 0, r_type = 96, idx = 0 '\000', tid = 0 '\000'}, sg = {pdata = 0x7f01ac301690, t_stats = 0x400, f_stats = 0x7f01ac30bea0, t_spd = 0x0,
f_spd = 0x0}}}

xubu1957 · Le 23/08/2022, à 08:44

Bonjour,

Comme demandé dans le premier message du tutoriel Retour utilisable de commande

Pour ajouter toi-même les balises code à ton précédent message #418 :

Cliquer sur le lien « Modifier » en bas à droite du message
Sélectionner le texte
Cliquer sur le <> de l'éditeur de message

Reading symbols from ./1fichierfs...
[New LWP 797832]
[New LWP 797878]
[New LWP 797825]
[New LWP 798888]
[New LWP 797827]
[New LWP 798311]
[New LWP 798821]
[New LWP 797830]
[New LWP 797831]
[New LWP 797828]
[New LWP 798312]
[New LWP 798389]
[New LWP 798827]
[New LWP 798703]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
--Type <RET> for more, q to quit, c to continue without paging--
Core was generated by `./1fichierfs /home/jenfi/WORK/1fichier -4 --api-key=@~/.1fichier.key --refresh-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000559a2687b7fe in orig_do_actions (pdata=0x7f01e6ffcc00) at astreamfs_worker.c:2085
2085            for (a = pdata->actions; NULL != a; a = a->next) {
[Current thread is 1 (Thread 0x7f01e6ffd6c0 (LWP 797832))]
(gdb) bt
#0  0x0000559a2687b7fe in orig_do_actions (pdata=0x7f01e6ffcc00) at astreamfs_worker.c:2085
#1  0x0000559a2687204e in do_actions (arg1=0x7f01e6ffcc00) at /home/jenfi/build/astreamfs/astreamfs_worker_dbg.c:694
#2  0x0000559a2687c308 in orig_async_worker (arg=0x7f01ed616ae8) at astreamfs_worker.c:2358
#3  0x0000559a26872588 in async_worker (arg=0x7f01ed616ae8) at /home/jenfi/build/astreamfs/astreamfs_worker_dbg.c:717
#4  0x00007f01edefa78d in ?? () from /usr/lib/libc.so.6
#5  0x00007f01edf7b8e4 in clone () from /usr/lib/libc.so.6
(gdb) print a
$1 = (struct action *) 0x7f065c2b4f34
(gdb) print *pdata
$2 = {fds = {{fd = 10, events = 1, revents = 1}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -15, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -18, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0,
      revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 1, revents = 0}, {fd = -1, events = 1,
      revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = -23, events = 0, revents = 1}}, now = 3785227,
  last_activity = 3785227, last_clean = 3785226, mfds = 0, n_files = 2, nst = 0, pst = 0, actions = 0x7f01ac3b4d30, owned_streams = 1 '\001',
  list = "\377\f\377\377\377\377\377\377\377\377\377\377\023\377\377\377\377\377\377?", '\377' <repeats 43 times>, "@"}
(gdb) print *pdata->actions
$3 = {next = 0x7f065c2b4f34, type = ACTION_CLOSE, sem_done = 0x0, a = {r = {fh = 139645160527504, bufp = 0x400, offset = 139645160570528, size = 0, written = 0, start = 0, idx = 0 '\000', tid = 0 '\000', map = 0 '\000',
      retry = 0 '\000'}, g = {buf = 0x7f01ac301690 "\024", offset = 1024, size = 139645160570528, written = 0, retry = 0 '\000'}, c = {fh = 139645160527504}, f = {fh = 139645160527504, tid = 0 '\000'}, t = {start = {
        tv_sec = 139645160527504, tv_nsec = 1024}, end = {tv_sec = 139645160570528, tv_nsec = 0}, fh = 0, sh = 0x0, fd = 0, err = 0, idx = 96 '`'}, ss = {start = {tv_sec = 139645160527504, tv_nsec = 1024}, end = {
        tv_sec = 139645160570528, tv_nsec = 0}, t_now = 0, fh = 0, written = 0, r_type = 96, idx = 0 '\000', tid = 0 '\000'}, sg = {pdata = 0x7f01ac301690, t_stats = 0x400, f_stats = 0x7f01ac30bea0, t_spd = 0x0,
      f_spd = 0x0}}}

grosjean · Le 23/08/2022, à 08:49

Sorry ...
Merci @xubu1957

Zakhar · Le 23/08/2022, à 09:02

Cool avec le debug des variables !..

J'ai bien reçu le fichier. Il démontre un crash mais pas le "bouclage", remarque ça pourrait être un bug commun.
En l'occurrence tu as l'air de faire pas mal de lecture aléatoire sur un fichier, car la fin atteint la limite des 16 streams par fichier. Dans ce cas on essaye de "recycler" un stream, et c'est sans doute là le bug. C'est un passage moins testé car la lecture aléatoire n'est forcément pas le point fort de 1fichierfs qui au contraire essaye de faire du "stream" (lecture séquentielle). Cependant j'ai aussi ça quand je lis des ISO, la lecture étant pas tout à fait séquentielle.

Quel que soit le driver, la lecture aléatoire en réseau est d'ailleurs pas terrible car à chaque tronçon lu on se paye le handshake https, etc...

Je regarde dans la semaine ton rapport de bug. Pour aujourd'hui l'emploi du temps est full

Si tu reproduis aussi le "bouclage", je veux bien également un fichier log.

A noter, j'ai en tête un "tweak" du moteur pour justement les cas de lecture "un peu" aléatoire. Je suis encore en train de réfléchir à comment l'architecturer... donc pas pour demain ! Il n'y a pas de secret cependant, ce sera au détriment de la mémoire consommée... aujourd'hui la consommation théorique en "buffers" est minimale à 512k par stream, soit 32Mo dans le cas extrême en 64bits. Si tu es prêt à "sacrifier" 1Go en buffers, on pourra potentiellement assouplir le "tronçonnage" !..

Dernière modification par Zakhar (Le 23/08/2022, à 09:06)

grosjean · Le 23/08/2022, à 09:16

Ici, j'utilise komga, qui est un "media server" pour comics. Du coup, il y a de l'analyse des fichiers, pour extraire les metadatas, le nombre de pages du comics, etc ...
Effectivement, avec plex, je n'ai pas de soucis ...
Pour la memoire, pas de soucis, ca tourne sur un nuc avec 16go.
J'essaye de repeter le probleme de bouclage...

Zakhar · Le 23/08/2022, à 09:32

grosjean a écrit :

Ici, j'utilise komga, qui est un "media server" pour comics. Du coup, il y a de l'analyse des fichiers, pour extraire les metadatas, le nombre de pages du comics, etc ...
Effectivement, avec plex, je n'ai pas de soucis ...
Pour la memoire, pas de soucis, ca tourne sur un nuc avec 16go.
J'essaye de repeter le probleme de bouclage...

Oui, pareil que quand je lis la "Playlist" d'un ISO vidéo. Certains bluray ont dans les 200 playlist, et la lecture de ces 200 fichiers n'est "pas tout à fait" séquentielle, même s'ils sont situées proches dans la structure de l'ISO.

Aujourd'hui "proche" est réglé au minimum constaté pour les utilitaires Linux, le readahead du kernel et de fuse, c'est à dire 4 blocs de 128ko. Ainsi si tu utilises du "standard", comme même par exemple faire un md5 sur un fichier, ça fera toujours du séquentiel et un seul stream, vraiment comme si le fichier était local.

Après effectivement quand on utilise des logiciels "un peu moins séquentiels", comme tu le fais avec Komga, ou moi avec mkvmerge pour extraire un mkv des playslists d'un BluRay ISO, eh bien 512k n'est "pas toujours assez" entre deux bouts que le programme client demande à lire.
L'optimal est en fait le quotient entre le temps pour ouvrir un stream et la lecture séquentielle d'un bloc de 128k. Sur 1fichier.com avec ma fibre Free à 1go, ça semble un facteur entre 30 et 60, c'est à dire qu'une ouverture de stream "coûte" entre 4 et 8 méga de lecture séquentielle. Ce qui veut dire que si le bout de fichier suivant à lire est à moins de 4Mo d'un bout en cours de lecture, on a intérêt à continuer à lire (même si on mettait à la poubelle !) plutôt que d'ouvrir un nouveau stream.

Elle est là "l'optimisation future" pour les lectures un peu moins séquentielles comme dans ton cas.

Après faut que je trouve une solution "propre" pour faire ça. Ce sera à l'utilisateur de passer le paramètre qui lui va. Mais monter à 8Mo de buffer par stream au lieu de l'actuel 512k (en dur) pourrait aider, au détriment bien sûr de la mémoire. Et l'option ultime serait que le programme trouve lui-même le "bon paramètre"... c'est pas pour demain, une chose à la fois.

Aussi quand on rajoute des fonctionnalités, on rajoute aussi des bugs... donc on va essayer de ne pas trop tout casser d'un coup !

Dernière modification par Zakhar (Le 23/08/2022, à 09:35)

Zakhar · Le 23/08/2022, à 18:08

J'ai bien le deuxième fichier aussi (la boucle). Merci pour le rapport très précis avec trace debug et même gdb !

Ça va m'aider à débusquer ce nouveau bug.

[Edit] en attendant j'ai réouvert le bug #5 sur le gitlab puisque c'est sans doute un bug un peu plus spécifique que le bug générique d'ouverture de stream que j'ai corrigé.

Dernière modification par Zakhar (Le 26/08/2022, à 07:20)

Zakhar · Le 26/08/2022, à 18:33

Bonjour @grosjean, j'ai trouvé où est le premier bug (crash) !
A chaque ouverture de fichier, on envoie son "file handle" au moteur pour fermer tout "file handle" identique ayant pu exister, car le "file handle" est juste une adresse mémoire en l'occurrence.

Il se trouve qu'il y a des réutilisations d'adresse mémoire pour des fichiers différents, et donc on rentre dans le cas (ce qui ne m'est jamais arrivé !)

Et là, l'ancienne adresse était sur le thread 1 alors que c'est toujours le thread 0 qui traite les "close". Le thread 0 détecte bien ça et envoie le message au thread 1... mais aussi il fait un "free" sur la zone contenant l'action !..
Donc quand celle-ci arrive au thread 0 qui la traite... eh bien on a un "use after free" et ça plante !..

En attendant que je trouve la meilleure manière de corriger, je pense que si tu tournes sur un seul thread, ce bug là ne se reproduira plus. L'autre ayant été corrigé (bug possible au démarrage de streams) cela ne devrait plus planter pour cette cause.

Tu sais déjà faire, mais il faut donc juste rajouter à ta ligne de commande :

--threads=1

... au passage tu vas donc tomber dans du code qui n'a jamais tourné sur mes machines, c'est le "nettoyage" des restes d'un ancien fichier qui occupait cette zone mémoire... espérons qu'il n'y a pas d'autres plantages là !..

Je vais regarder aussi le "bouclage" pour voir si ça pourrait venir de la même cause, ou si c'est autre chose.

[Edit] la boucle à l'air d'être un autre bug sur la machine à état des streams, visiblement rien à voir avec le "close" que j'ai corrigé localement (je vais tester avant de "commiter" !..) et qui se contourne temporairement en limitant à 1 thread. Je n'ai pas encore trouvé d'où ça pouvait bien venir.

Dernière modification par Zakhar (Le 26/08/2022, à 23:01)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#401 Le 06/03/2022, à 22:51

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#402 Le 18/03/2022, à 07:29

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#403 Le 10/04/2022, à 15:04

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#404 Le 10/04/2022, à 16:35

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#405 Le 10/04/2022, à 17:10

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#406 Le 01/05/2022, à 10:14

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#407 Le 05/05/2022, à 09:42

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#408 Le 05/05/2022, à 10:30

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#409 Le 05/05/2022, à 10:59

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#410 Le 05/05/2022, à 12:03

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#411 Le 07/05/2022, à 10:12

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#412 Le 08/05/2022, à 19:56

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#413 Le 29/07/2022, à 09:09

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#414 Le 06/08/2022, à 14:39

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#415 Le 22/08/2022, à 17:01

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#416 Le 22/08/2022, à 23:07

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#417 Le 23/08/2022, à 08:05

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#418 Le 23/08/2022, à 08:43

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#419 Le 23/08/2022, à 08:44

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#420 Le 23/08/2022, à 08:49

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#421 Le 23/08/2022, à 09:02

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#422 Le 23/08/2022, à 09:16

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#423 Le 23/08/2022, à 09:32

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#424 Le 23/08/2022, à 18:08

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#425 Le 26/08/2022, à 18:33

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

Pied de page des forums