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

Zakhar · Le 28/02/2021, à 12:03

Si, si, les notifications c'est revenu !

C'est juste que pour éviter de polluer de messages, je fais des [Edit] et il n'y a pas de notifications sur messages modifiés.

Ce matin, corrigé un bug dans la déduplication qui cassait une autre partie dans certain cas. Repassé tous les tests de non-régression à la fois sur le PC et le Raspb-Pi. Et je continue l'observation pour voir si je ne débusque pas d'autres bugs...

C'est un peu "sioux" le rename sur fichier existant parce que Linux permet des choses qu'on n'imagine même pas faire, mais qui pourtant sont possibles et doivent donc être testées avec le driver.

Par exemple, tu as GrosFiciher1 (10Go), GrosFichier2 (12Go), tu lances en parallèle la copie de GrosFiciher1 wers Copie1 et la copie de GrosFiciher2 vers Copie2.
Ca va donc prendre un peu de temps puisque les fichiers sont gros (exprès pour qu'on ait le temps de faire la manip ci-dessus).

Et pendant que ça copie, tu renommes Copie1 en Copie2.

Oui, c'est stupide direz-vous puisque en définitive on va avoir écrasé la "Copie2" par Copie1, et on a donc copié 12Go pour rien.

Eh bien comme Linux par défaut ne met pas de "locks" (contrairement à d'autres O.S. bidon !) la manipulation ci-dessus est tout à fait possible et fonctionnelle, et les copies continuent normalement. La deuxième copie sera effectivement supprimée à la fin !

Ce qu'il se passe en réalité c'est que Linux travaille avec des "inodes" et compte les "liens" vers les "inodes". Quand on fait les copies, elles vont chacune dans un "inode" différent, lequel possède des liens actifs via les fichiers ouverts (pendant la copie) et via les entrées de répertoires.
Lorsque qu'on renomme pendant la copie, en réalité on agit juste sur le répertoire qui contient Copie2 et le fait de renommer Copie1 en Copie2 fait que l'ancien "inode" de Copie2 n'a plus de "lien" depuis une entrée de répertoire. Mais pour autant l'inode de Copie2 a toujours un lien tant que la copie se déroule puisqu'on a un handle de fichier ouvert vers cet inode. A la fin de la copie, le fichier est fermé, et l'inode de Copie2 n'a alors plus aucun lien, le système va donc le supprimer.

Si vous faites la manipulation ci-dessus sur un "vrai disque", vous aller voir les deux copies tourner même après le renommage, et l'espace disque diminuer jusqu'à 22Go (10 + 12) pendant la copie. Puis une fois la copie vers Copie2 terminée, l'espace disque va remonter d'un coup de 12Go puisque l'inode est supprimé n'étant plus accessible par aucun lien.

Si vous faites ça en copiant Copie1 et Copie2 via 1fichierfs :
- Ça fonctionne
- C'est optimisé dans le sens où 1fichierfs se rend compte que la copie vers Copie2 ne sert plus à rien, et il arrête donc, pour ce fichier, d'envoyer les octets via ftp, et même la partie qui a déjà été envoyée est supprimée. Donc en réalité la copie vers Copie2 va se dérouler à toute vitesse... du moins à la vitesse de lecture du fichier à partir duquel vous copiez, puisque le driver ne fait plus véritablement de copie. C'est comme si à ce moment là, vous copiiez vers /dev/null (*)
- Ce n'est malheureusement pas "atomique"... mais la limitation vient principalement de 1fichier.com (et de certaines parties "imparfaites" du driver dans ce cas précis !).
- Inutile d'observer l'espace disque : il n'est mis à jour qu'une fois le fichier déplacé du serveur ftp vers le stockage, et de toute façon 1fichier.com limite cette API là à un appel toutes les 5 minutes, ce que le driver respecte ! Donc en clair, vous ne verrez pas l'espace libre sur votre stockage "bouger" pendant la copie, et de toute façon cet espace libre, au mieux, est actualisé toutes les 5 minutes (limitation du serveur).

Voila pourquoi renommer vers fichier existant était difficile... et jusqu'à présent comme personne n'en avait eu besoin, ça répondait juste "impossible" !..

(*) cette optimisation existait déjà. On peut la constater de façon plus simple en supprimant la cible d'un fichier qu'on est en train de copie... oui, oui, ça marche aussi pour la même raison que ce qui est expliqué ci-dessus avec le renommage, c'est juste plus "simple" avec un seul fichier qu'on copie, et on supprime la cible vers laquelle on copie pendant que la copie tourne !

Dernière modification par Zakhar (Le 28/02/2021, à 12:25)

Zakhar · Le 02/03/2021, à 22:06

(2 Mars 2021) Version 1.8.3

Nouveautés par rapport à la 1.8.2

Fonctionnalié : "dé-duplication". Si plusieurs fichiers du même répertoire ont le même nom (c'est possible sur 1fichier.com) seul le plus récent sera montré. Lorsque qu'un répertoire a le même nom que des fichiers dans le même répertoire parent (également possible) seul le répertoire est montré, les fichiers sont cachés.
Fonctionnalié : la fonction de renommage d'un fichier vers un fichier existant est désormais implémentée. Elle n'est pas "atomique" comme le voudrait POSIX, c'est une limitation du service 1fichier.com.
Bug : dans certains cas bien particuliers (montage autre que la racine) un bug de produisait au renommage d'un fichier écrit (upload) avant la fin du cycle d'upload.
Documentation le manuel a été mis à jour pour expliquer les deux nouveautés.

Mise à jour : version apportant des fonctionnalités
Mis à part le bug signalé qui peut vous toucher s'il vous arrive de monter autre chose que la racine de votre compte 1fichier, cette version est surtout là pour apporter des fonctionnalités.
Si les fonctionnalités ne vous sont pas nécessaires, la mise à jour n'est pas urgente.
Les fonctionnalités apportées permettent par exemple d'utiliser plus facilement rsync puisque celui-ci va, par défaut, dans le cas où un fichier a été modifié, commencer par créer un nouveau fichier temporaire avec le nouveau contenu modifié, et une fois le fichier écrit, va faire un renommage (ce qui supprime l'ancien fichier car c'est un renommage "vers fichier existant", qui écrase donc la cible).

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

$ stat -c "%s %n" 1fichierfs_1.8.3~buster-1_armhf.deb; sha256sum 1fichierfs_1.8.3~buster-1_armhf.deb; md5sum 1fichierfs_1.8.3~buster-1_armhf.deb 
84788 1fichierfs_1.8.3~buster-1_armhf.deb
6b3d4d18ed3e292fd0a3ec1cbc7e89781768127863689dfa58136369f9399562  1fichierfs_1.8.3~buster-1_armhf.deb
31c0c0ea11f541e56cd805182dfd6ca8  1fichierfs_1.8.3~buster-1_armhf.deb

Jarodd · Le 05/03/2021, à 10:00

Bonjour,
J'ai souvent des erreurs sur des petits fichiers (txt, wav). Cela fait tomber le montage (je ne sais pas si c'est le bon terme : je dois faire fusermount -u puis refaire 1fichierfs pour me reconnecter).
Ce matin, cela s'est produit plusieurs fois, en un laps de temps assez court. Cela a bloqué mon compte 1Fichier (téléchargement et envoi).
Je ne sais pas ce que je peux fournir pour aider au débug : des logs, des screenshots ?

Zakhar · Le 05/03/2021, à 10:06

Bonjour Jarodd,

Oui, il faut une "log" pour que je puisse faire qq chose.

Tu peux commencer par rajouter dans les options de montages :

--log-level=6 --log-file=/tmp/debug.txt

Quand ça a planté, tu fais le fusermount -u et tu m'envoie le fichier /tmp/debug.txt en MP (tu peux bien sûr mettre le fichier de "debug" où tu veux en adaptant les options ci-dessus).

Si je n'arrive pas à voir suffisamment avec le niveau de log 6, il faudra passer au 7, mais pour cela il te faut le programme avec les traces de debug et donc le compiler depuis le source pour avoir à l'idéal la log niveau 7 et le crashdump avec les symboles qui montrent où ça plante.

Donc commençons par l'étape ci-dessus qui est plus simple pour voir si elle me donne une piste du crash.

Désolé pour le "ban" 1fichier, il est possible que le crash ait effectivement provoqué un comportement incorrect du driver qui est analysé par 1fichier comme un "spam". C'est d'ailleurs aussi possible que l'inverse de produise : c'est 1fichier.com qui bannit et une mauvaise interprétation des "cas d'erreur" (moins testés) provoque un crash.

Le 'ban' est temporaire quoi qu'il en soit !

...piste possible (je le verrai avec la log demandée), si tu uploade "beaucoup de petits fichiers", le driver va demander à chaque fois un "déclenchement FTP". Comme tu est sans doute par défaut en "FTP automatique", cela provoque une erreur 403 (allez savoir pourquoi !) et 1fichier.com n'aime pas trop les 403.
Sauf qu'ici on boucle, parce qu'on ne peut pas non plus interroger l'état du FTP (automatique ou pas) au rythme où on veut !..

Un test que tu peux faire pour confirmer la piste est de passer le FTP en manuel (c'est beaucoup moins testé donc pas trop conseillé) pour voir si ça cesse de planter... mais la "log" m'intéresse toujours :
- pour traiter le "problème" avec la "team 1fichier"
- pour mieux réagir qu'un "crash" en cas d'erreurs.

Dernière modification par Zakhar (Le 05/03/2021, à 10:15)

Jarodd · Le 05/03/2021, à 11:02

Ok dès que je récupère l'accès, j'actives ces logs.
Pour info, je n'utilise pas un client FTP, mais DoubleCommander.

Zakhar · Le 05/03/2021, à 11:43

Pas de problème Jarodd, je parlais du FTP utilisé en interne par 1fichierfs.

Pour changer le réglage il faut que tu ailles sur ton espace "web" https://1fichier.com et dans la rubrique "Gestion FTP".

Mais avant de changer quoi que ce soit, si tu peux me faire la "log" demandée, ça aidera.

Précisément, l'intérêt d'un driver fuse est que tu peux utiliser le logiciel que tu veux "par dessus" et ce logiciel voit le montage comme si c'était "une clé USB", c'est à dire comme le fichiers étaient locaux... aux restrictions près dues au service à distance (pas "d'écriture aléatoire").

Dernière modification par Zakhar (Le 05/03/2021, à 11:46)

Zakhar · Le 05/03/2021, à 17:43

Je viens de vérifier, en réalité le changement d'option dans "Gestion FTP" ne devrait pas influer car l'API "ftp/process" rend correctement un status 200 même dans le cas où elle est inutile car on est en automatique.
Donc le bannissement ne peut pas venir de ça.

Je viens d'en balancer 20 à la chaîne, ça n'a pas bronché... tout continue de fonctionner.

J'ai donc bien besoin d'une "log" pour tâcher d'avoir une hypothèse sur ce qu'il peut se passer !

Dernière modification par Zakhar (Le 05/03/2021, à 17:47)

Zakhar · Le 06/03/2021, à 10:11

Des nouvelles Jarodd ?

En attendant quelques conseils.

C'est exact que 1fichier.com n'est pas vraiment adapté à gérer un myriade de petits fichiers, mais c'est le cas général de tout stockage à distance. Même sur un disque local, les "petits fichiers" peuvent saturer le disque par consommation des "inodes" avant que celui-ci soit plein à sa capacité max. Sur le stockage distant c'est pareil et encore plus inefficace à cause de la latence réseau.

1fichierfs a cependant été adapté (dans la mesure de ce qui est possible avec le serveur) ce qui me permet d'avoir ma collection de CD-reapés "en ligne", pour un peu plus 1000 fichiers musicaux.
J'utilise principalement mocp un lecteur audio très geek puisque en ligne de commande et lui ne pose aucun problème particulier.

Par contre si tu veux utiliser le "standard" Rhythmbox, celui-ci va, comme beaucoup de lecteurs, commencer par faire un scan de la bibliothèque audio en ouvrant tous les fichiers.
Et là, au moins la première fois, ça va prendre du temps... et planter (voire bannir si tu insistes) si tu n'as pas pris la précaution de mettre "l'identification réseau"

Pour cela il faut :
- Que tu récupères ton adresse IP publique (celle fournie par ta box)... en espérant pour toi que tu es chez un "bon opérateur" (comme Free), chez qui tu as par défaut une IP fixe.
- De préférence l'ipV4 pour permettre à plusieurs machines de ton réseau local d'accéder en même temps, ci c'est un de tes besoins
- Déclarer l'ip publique ainsi récupérée dans la partie "Identification Réseau" que tu trouveras sous la rubrique "Mes paramètres" de ton interface web 1fichier.com
- Forcer l'ipV4 pour 1fichier (pour le partage derrière ta box) en rajoutant l'option -4 au lancement

Et là, Rhythmbox va pouvoir indexer tranquillement la collection de 1000+ musiques, ou pareil pour Shotwell avec tes 10000 photos perso. Mais bon, le "scan" n'est vraiment pas performant par rapport à un disque local (surtout SSD) à cause de la latence réseau liée à l'accès à distance, les handshakes TLS et tout le toutim !..

Une jolie image illustre ça :
Latences comparées

Pour le stockage à distance tu es plutôt dans le tout dernier cas en rouge à une échelle de magnitude plus inefficace que l'accès disque.

Par contre sur la lecture séquentielle de gros fichiers, c'est principalement l'optimisation de 1fichierfs, seule l'ouverture et les premiers octets sont chers, ensuite tu es "à la vitesse du réseau", ce qui est devenu "raisonnable" avec la fibre.

Dernière modification par Zakhar (Le 06/03/2021, à 10:14)

Jarodd · Le 07/03/2021, à 09:10

Bonjour,
Désolé quand je n'ai pas de notif j'oublie de passer régulièrement !
J'ai enregistré mon ip dans les paramètres réseau, merci de l'info.
Pour le fichier de log, tu peux le trouver ici :
https://1fichier.com/?om38bw2eqgrhnlimo0rg
Je l'effacerai quand tu auras confirmé l'avoir récupéré.

Zakhar · Le 07/03/2021, à 09:46

Merci Jarodd, tu peux effacer, je regarde.

Je constate deux choses :
- tu as plein de fichiers qui polluent ton répertoire /.upload.1fichierfs. Il s'agit d'envois précédents où le logiciel a "crashé" et on ne sait pas quoi en faire. Tu peux supprimer les plus anciens (27h) via 1fichierfs et les plus récents sur l'interface web.
- le logiciel que tu utilises (DoubleCommander ?) a l'air de faire plein de copies en parallèle car je vois une terminaison de copie sur les 4 "writers" en même temps et ensuite plus rien... sans doute un crash

Compte tenu de la façon actuelle dont fonctionne l'upload, ce n'est pas le plus efficace de faire ainsi et en tout cas ça bloque à 4 uploads. Il y a peut-être un bug au moment où on "débloque" quand les 4 writers ont été saturés, je regarde ça.

L'algorithme que je prépare pour la lecture sera aussi appliqué pour l'écriture et ne se basera plus sur un nombre fixe ni n'obligera à avoir des "threads" dédiés. En fait il utilisera les "thread" de fuse. Pour la partie écriture j'attends la nouveauté de 1fichier.com (upload spécial http pour abonnés) pour le coder.

Dernière modification par Zakhar (Le 07/03/2021, à 09:58)

Zakhar · Le 07/03/2021, à 10:09

Ok, dans le cas où les "writers" sont tous occupés (ton cas) il y a potentiellement un bug effectivement car l'ordre pour marquer qu'un "writer" est libre n'était pas le bon (inversion entre un flag atomique et un sémaphore).

Tu peux me dire quand quelle version d'Ubuntu tu es, je te "build" une version avec "debug" pour voir si le bug venait bien de ça.

C'est assez difficile à reproduire de mon côté car c'est un bug de "parallélisme", donc selon la vitesse du proco, le nombre de coeurs, etc... ça se produit ou pas quand on rentre dans cette zone là !..
Et lorsque (par chance/malchance !) ça se produit, ça ne fait "que" écraser une zone de données... ce qui veut dire que selon ce qu'on avait à cet endroit, on crash rapidement, on crash plus loin, ou pas du tout en produisant éventuellement des résultat inattendus (comme tout écrasement mémoire).

A noter que lorsque les "writers" sont saturés, pour ne pas bloquer tout le fonctionnement (fuse est assez sensible si le driver ne répond pas !) on retourne l'erreur

EAGAIN Resource temporarily unavailable

(Ressource temporairement indisponible) au bout d'une seconde sur l'appel de "open" du client.

Le logiciel client est alors sensé réagir en essayant de recommencer le "write"... certains ne sont pas bien codés et pourraient faire des erreurs !..

Le fonctionnement "en parallèle" que je constate peut effectivement venir du fait qu'il s'agit de "petit fichiers". En effet, dans ce cas l'écriture asynchrone met tout en mémoire (mini 64k, maxi 128k) et fait croire à l'appelant que c'est fait alors qu'en réalité l'écriture continue en tâche de fond. Par conséquent le fait d'uploader une série de petits fichiers, par effet de cette écriture en tâche de fond, va effectivement "consommer" des "writers" !

Cependant, regarde quand même dans les paramètres de ton logiciel (DoubleCommander) s'il y a des options pour faire des copies "en parallèle" (comme par exemple dans FileZilla) et dans ce cas réduis à 1 copie à la fois (ou 2 max).

[Edit] : bon, en fait le fait de renvoyer EAGAIN sur un "write" n'est même pas compatible avec un simple "cp". Donc tant pis, en attendant le prochain changement d'algorithme on "bloque" quand tous les "writers" sont occupés. J'ai fait le test avec 100 fichiers aléatoires de 63k, le write s'est bien passé via xargs avec 3 copies en parallèle ! La comparaison -aussi 3 en parallèle- est également Ok.

Pas de crash en faisant ainsi non plus.

En fait, comme c'est niveau "bug" (comportement incompatible avec cp) et produit des crash aléatoires, je vais faire une version d'urgence, donc pas besoin de "spécial debug" Jarodd !

Merci pour le signalement.

Un nouveau package (correction en urgence) sera en ligne d'ici la fin de cet après-midi.

Dernière modification par Zakhar (Le 07/03/2021, à 12:01)

Jarodd · Le 07/03/2021, à 12:21

Oui c'est bien DoubleCommander que j'utilise. Je le préfère à un client FTP car il permet d'appairer des dossiers et de voir les différences.
Les copies en parallèle, je n'en fais plus aujourd'hui. Je le faisais au début de mon abo 1F (en janvier) mais ayant constaté que cela plantait souvent, j'ai arrêté. Je ne suis pas si pressé de faire mes backups, je préfère plus long mais plus stable.
Je vais également vider le répertoire upload.1fichierfs.

Zakhar · Le 07/03/2021, à 12:59

Ok, et ta version d'Ubuntu était dans ta signature !

Je nettoie le code, refais le test de non-regression, et fais une version dans l'aprem si tout va bien.

Quant à la stabilité, la partie lecture est bien stable (elle est plus ancienne), mais la partie écriture est affreusement complexe à cause des limitations de 1fichier.com

Donc tant qu'ils ne livrent pas, comme ils l'ont évoqués, un "upload pour les abonnés" en http (supportant le "chunked encoded") il n'y a guère d'espoir d'améliorer la stabilité. Avec ce qui est promis (sans date) par la "team 1fichier", ça va simplifier le code de la partie write très considérablement et donc sera bien plus stable... une fois les "bugs de jeunesse" du nouveau code fixés !..

L'obligation actuelle de passer par FTP pour l'upload m'a même fait déclarer des "bugs" à libcurl, une des librairies les plus utilisées au monde !.. Le bug déclaré il y plus de quatre mois, et n'est toujours pas corrigé sur cette librairie...
Il est actuellement "contourné" dans 1fichierfs car il concerne TLSv1.3, et simplement l'upload FTP de fait en TLSv1.2 qui n'a pas ce bug.
Au passage en http, on ne devrait pas avoir le bug en upload (en tout cas je ne l'ai pas constaté aux tests que j'ai faits).

Par conséquent, la correction du bug étant limitée, il n'y a pas de risque à packager rapidement.
J'ai juste corrigé un autre bug "évident" (écriture sur pointeur NULL), mais je n'investis pas trop dans la perfection du code "écriture" puisqu'il va disparaître ou être remplacé dès que la "team 1fichier" a livré le nouveau protocole.

(P.S.: je me suis "banni" mon IP en faisant des tests en parallèle... mais du coup ça me permet de tester en ipV6 !)

Dernière modification par Zakhar (Le 07/03/2021, à 15:04)

Zakhar · Le 07/03/2021, à 16:15

(7 Mars 2021) Version 1.8.4

Nouveautés par rapport à la 1.8.3

Bug : le fait de retourner EAGAIN lorsque tous les "writers" étaient occupés n'était pas compatible avec des utilitaires standard comme 'cp' et provoquait un crash. Désormais le driver attend un "writer" libre.
Bug rare: dans un cas qui ne se produit que si vous jouez avec le répertoire .upload pendant que le driver tourne, écriture sur un pointeur NULL en cas de suppression d'un fichier écrit et supprimé.

Mise à jour : correction de bugs
Les bugs corrigés ne concernent que la partie écriture.
Compte tenu de l'algorithme actuel, le bug et le crash se produisait à peu près systématiquement en copiant une série de petits fichiers. [Signalement ci-dessus par Jarodd]

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

$ stat -c "%s %n" 1fichierfs_1.8.4~buster-1_armhf.deb; sha256sum 1fichierfs_1.8.4~buster-1_armhf.deb; md5sum 1fichierfs_1.8.4~buster-1_armhf.deb 
84728 1fichierfs_1.8.4~buster-1_armhf.deb
a0cdadf85953c5c574958d6c5a222a9200d6eb1834b5a4787117ac3ea92a0c1f  1fichierfs_1.8.4~buster-1_armhf.deb
0a32a8ca90ae25c879fd1ef8fbe518a6  1fichierfs_1.8.4~buster-1_armhf.deb

Dernière modification par Zakhar (Le 07/03/2021, à 16:46)

Jarodd · Le 08/03/2021, à 11:49

1.8.4 prise, merci, je reteste dès que possible

Zakhar · Le 08/03/2021, à 16:48

J'ai testé avec la copie de 100 petits fichiers en les faisant par 3 en parallèle (avec xargs), tout s'est bien passé. Fichiers uploadés et vérifiés, pas de crash.

... mais bon, il peut toujours y avoir des "cas particuliers".

Jarodd · Le 09/03/2021, à 14:14

Hé bien j'ai le plaisir de te confirmer que ça fonctionne nickel ! Je n'ai pas eu une seule erreur avec le répertoire que je transférais depuis des jours (j'avais abandonné tellement ça plantait souvent).
Bien joué !

Zakhar · Le 09/03/2021, à 15:30

Pas de problème, c'est l'algorithme initial qui était foireux en fait, merci d'avoir fait le signalement !

Jarodd · Le 09/03/2021, à 21:53

Finalement j'ai eu quelques erreurs vers la fin des transferts : uniquement des fichiers txt à 0 ko (certains sont réussis, ce n'est pas systématique).

Zakhar · Le 09/03/2021, à 22:00

Oui, ça c'est normal car 1fichier.com ne supporte pas les fichiers vides !

Le driver les supporte, et fait comme si le fichier était présent, mais cela n'est valable que pour la durée où le driver est lancé. Donc la fois suivante où le PC sera rallumé (ou simplement démonter/remonter le montage), les fichiers vides auront disparu.

Mais en principe ça ne devrait pas faire "d'erreur" sur un fichier vide... pourrais-tu détailler ce que tu considères comme "erreur" ? C'est avec rsync ou un autre programme ? Des messages d'erreur particulier ?

Quoi qu'il en soit, à part réparer ces "messages d'erreur" si je peux identifier d'où ils viennent, il n'est pas grand chose que le driver puisse faire pour le "stockage de fichiers vides" puisque ce n'est pas supporté par 1fichier.com. Aucun problème par contre dès que le fichier contient au moins 1 octet !

Donc en pratique, si tu utilises rsync pour synchroniser, il devrait systématiquement recopier les fichiers vides puisqu'ils auront disparu d'une fois sur l'autre. Ce n'est pas bien dramatique car la simulation d'un fichier vide ne fait pas d'accès au serveur, ce n'est que du programme local, vu que de toute façon le serveur ne les gère pas. Donc en principe créer des fichiers vides sur 1fichierfs est super rapide (une fois que le répertoire parent a été lu depuis le serveur).

Dernière modification par Zakhar (Le 09/03/2021, à 22:05)

Jarodd · Le 10/03/2021, à 17:45

Bonjour,
C'est une erreur via DoubleCommander : "Erreur lors de l'écriture dans le fichier /path/to/file: Remote I/O error"
Je n'ai pas encore fini tous mes envois, je mettrai rsync en place à la fin.

Zakhar · Le 10/03/2021, à 22:35

"Remote I/O Error" est renvoyée quand on récupère une erreur du serveur ou quelque chose d'inattendu.

Si tu as un journal ça peut aider à diagnostiquer.
Tu peux d'ailleurs y regarder toi-même si tu te souviens le nom du fichier qui a planté.

/usr/include/asm/errno.h a écrit :

#define EREMOTEIO 121 /* Remote I/O error */

Donc tu dois avoir dans le journal un truc qui a retourné -121 (puisque c'est dans une écriture, on retourne un négatif sinon cela voudrait dire un nombre d'octets écrits).

Tu peux aussi faire ça pour voir toutes les erreurs :

$ grep ERROR /tmp/debug.txt 
[1fichierfs     4.279] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/user/info.cgi` name=`/`.

Là c'est une erreur "normale" au démarrage. Le driver vient d'être lancé et il cherche à récupérer l'espace disponible, mais ce point d'entrée de l'API ne peut être appelé qu'une fois toutes les 5 minutes, et quand tu viens de lancer, tu ne sais pas si une autre instance avant n'avait pas appelé dans les 5 minutes précédentes (mon Raspberry Pi que je viens d'éteindre avait dû utiliser le point d'entrée trop récemment).

Pareil pour les "warning" (etc...)

$ grep WARNING /tmp/debug.txt 
[1fichierfs     0.000] WARNING: debug messages not present in this executable. Please run make with DEBUG=1

Idem, je lance toujours avec le mode Debug (7) mais comme c'est la version packagée 1.8.4 qui tourne, elle n'a pas les messages de DEBUG, et donc c'est comme si on avait mis le niveau Info (6).

Il peut effectivement arriver une micro-coupure réseau ou serveur qui fasse planter le transfert FTP, ça on n'y peut pas grand chose hélas... juste recommencer le fichier qu'on était en train de copier !
Le driver n'essaye pas de "recommencer" tout seul. Ce serait un algorithme compliqué, et ça ne marchera plus avec le http upload qui arrive contrairement à FTP où il est possible de recommencer où ça a planté avec un "append".

Si c'est sur un fichier de taille zéro, comme tu le disais précédemment... là ce serait plus étonnant car un bug. Le seul accès serveur que peut déclencher un fichier vide est la lecture des répertoires parent. Mais s'il se produit une erreur pendant cette lecture, l'erreur est journalisée et les répertoires sont affichés comme s'ils étaient vides. C'est la librairie fuse qui fait ces accès avant de créer le fichier vide et donc il ne peut jamais y avoir cette erreur "Remote I/O" (logiquement et sauf bug !) dans le cas d'un fichier vide.

Dernière modification par Zakhar (Le 11/03/2021, à 07:54)

Jarodd · Le 06/04/2021, à 13:29

Bonjour,
J'ai une question concernant le "cache" du transfert des fichiers. Je viens de m'apercevoir que j'ai des centaines de répertoires/fichiers dans .upload.1fichierfs, dont un grand nombre qui date de plusieurs semaines. Je pense qu'ils ne devraient pas y être. Or avec l'interface de 1Fichier, impossible de les supprimer. Y a-t-il un moyen pour le faire depuis la gestion des fichiers en local ? (depuis le montage)
Merci

Edit 07/04 : c'est bon j'ai réussi à supprimer le répertoire depuis 1F. Je recommence mes envois, je vais mieux le surveiller désormais.

Dernière modification par Jarodd (Le 07/04/2021, à 15:20)

Jarodd · Le 25/04/2021, à 17:58

Bonjour,
Il y a du nouveau sur l'API qui est en discussion avec l'équipe de 1F (message #293) ? (je suis peut-être trop curieux, mais j'ai été appâté )
J'en profite pour dire que la dernière version est vraiment bien, je n'ai plus d'erreurs, sur plusieurs Go de transfert, je n'ai plus du tout rencontré les erreurs du début. Donc encore merci pour 1fichierfs, c'est vraiment très pratique !

Zakhar · Le 25/04/2021, à 20:21

Non Jarodd, pas ne nouveau pour le moment. Mais ils avaient été clairs que c'était pour eux "basse priorité" !..

C'est déjà bien qu'ils aient réfléchi, m'aie interrogé, et aient pensé à une solution autour d'un http spécifique permettant le "chunk upload".

Aussi en ce moment je n'ai pas trop le temps à cause du boulot, et en parallèle je refais complètement l'architecture de la lecture. Elle ne va plus utiliser des "readers" spécifiques, mais la lecture se fera sur le thread fuse à la place. Ainsi on aura 4 "streams" par fichier au lieu de 4 streams en tout.
Pour l'écriture je ferai ensuite pareil, et ça devrait être plus simple car l'écriture est en fait davantage séquentielle que la lecture pour des raisons évidente que l'ordre d'écriture importe, le système ne peut guère paralléliser, et ça rend le boulot du driver plus facile. De la sorte, il n'y aura plus aucune limitation à 4 fichiers écrits en parallèle. C'est en fait le kernel et les librairies fuse qui vont limiter, mais c'est paramétrables comme bien des aspects du kernel.

Je m'attaquerai à la partie écriture soit après la lecture, soit avant si 1fichier fait l'évolution attendue.

Ne t'inquiète pas, quand ils auront fait l'évolution, ils devraient me prévenir. Ils savent que je suis un "client" pour ça et que je leur fais des retours si je vois de "bugs".

Dernière modification par Zakhar (Le 25/04/2021, à 20:23)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#301 Le 28/02/2021, à 12:03

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

#302 Le 02/03/2021, à 22:06

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

#303 Le 05/03/2021, à 10:00

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

#304 Le 05/03/2021, à 10:06

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

#305 Le 05/03/2021, à 11:02

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

#306 Le 05/03/2021, à 11:43

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

#307 Le 05/03/2021, à 17:43

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

#308 Le 06/03/2021, à 10:11

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

#309 Le 07/03/2021, à 09:10

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

#310 Le 07/03/2021, à 09:46

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

#311 Le 07/03/2021, à 10:09

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

#312 Le 07/03/2021, à 12:21

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

#313 Le 07/03/2021, à 12:59

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

#314 Le 07/03/2021, à 16:15

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

#315 Le 08/03/2021, à 11:49

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

#316 Le 08/03/2021, à 16:48

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

#317 Le 09/03/2021, à 14:14

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

#318 Le 09/03/2021, à 15:30

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

#319 Le 09/03/2021, à 21:53

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

#320 Le 09/03/2021, à 22:00

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

#321 Le 10/03/2021, à 17:45

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

#322 Le 10/03/2021, à 22:35

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

#323 Le 06/04/2021, à 13:29

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

#324 Le 25/04/2021, à 17:58

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

#325 Le 25/04/2021, à 20:21

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

Pied de page des forums