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

Zakhar · Le 13/09/2024, à 23:12

Oui Z3ndra, il y a un bug connu. Les fichiers ne sont pas "corrompus" mais parfois la version actuelle se plante, et il n'y a effectivement pas d'autre solution que de tuer le process et relancer.

C'est corrigé depuis un moment chez moi, mais je n'ai pas encore eu le temps de packager, beaucoup de travail et d'activités à côté.

Le github est à jour cependant, tu peux compiler la dernière version corrigée depuis celui-ci. Comme je rentre, en plus du travail, dans un période de travaux au domicile de ma mère, je ne suis pas sûr d'avoir le temps de faire la package de si tôt hélas.

Mais je note ta demande, comme jusqu'à présent personne n'avait rien dit je présumais que ça ne gênait pas, et je vais monter la priorité de cette tâche.

Aussi, il va falloir que je rajoute la version packagée pour 24.04 en espérant que le tuto antique que j'ai suivi y fonctionne toujours !

Dernière modification par Zakhar (Le 13/09/2024, à 23:15)

z3ndra · Le 22/09/2024, à 13:12

Ca marche merci pour ta réponse, je vais plutot attendre la version packagée ça sera plus simple. Vraiment hate. Apres en attendant j’ai mit un script qui verifie l’accessibilité d’un fichier toute les 10 min et si il est inaccessible parce que ça a planté, ca le demonte et le remonté automatiquement mais ça reste relou lol

z3ndra · Le 26/09/2024, à 12:06

salut, j'ai aussi remarqué un truc , c'est que 1fichierfs se met a consommer enormement de ressources cpu, ce qui freeze le serveur à la longue.

Zakhar · Le 09/10/2024, à 23:25

Oui @z3ndra !
Ça fait partie du bug connu. Quand le bug se produit, ça peut planter, mais aussi les requêtes peuvent se mettre à tourner sans fin entre les threads, et du coup ce n'est pas planté, mais le fichier qui était lu est bloqué, et le CPU monte en flèche à cause du passage en boucle sans fin entre threads. Dans ce cas là : kill + fusermount -u

Il est possible que l'option -o sync_read fasse disparaître le bug puisqu'il se produit quand on a plusieurs requêtes en parallèle a début d'un fichier, mais cela peut aussi avoir un impact sur la performance... à tester donc !

Je viens de faire le dernier test qui nécessite de changer un paramètre interne pour forcer certaines choses à se produire, et ça fonctionne comme prévu.
J'ai "taggé" la version 1.9.5 sur le gitlab, elle est prête pour la release.

Je vais mettre à profit la grippe/arrêt de travail pour tâcher de vous packager cette 1.9.5 qui corrige ces méchants bugs de synchro.
Aussi elle apporte la "log circulaire" que j'ai mise en place précisément pour attraper ce bug de boucle infini. La log étant vite pleine en mode debug, je n'avais pas la "fin". Avec le système circulaire, si on tue le programme suffisamment vite quand la boucle infinie se produit, on peut avoir l'instant qui a déclenché la boucle-bug.

Aussi il va falloir que je songe à 2 trucs pour le futur :
- déprécier la 16.04, en effet elle oblige à maintenir des paramètres de compilation spécifiques (gnutls au lieu de openssl)
- regarder fuse 3 qui est le fonctionnement par défaut au moins sur la 24.04 (et peut-être déjà en 22.04 !). Fuse 2 est toujours supporté bien sûr... heureusement !

Dernière modification par Zakhar (Le 10/10/2024, à 00:01)

Zakhar · Le 10/10/2024, à 16:40

(10 octobre 2024) Version 1.9.5

Nouveautés par rapport à la 1.9.4

Fix bugs/crashes : crash ou boucle infinie (avec forte consommation de CPU) lors d'inversion des premières requêtes de lecture d'un fichier.
Fix bugs/crashes : crash/bug théorique quand un fichier est abandonné (time out interne) et au même moment rouvert.
Nouvelle LTS : le logiciel est désormais également packagé pour la dernière LTS : Noble Numbat - 24.04.
Fonctionnalité : possibilité de limiter la taille du fichier journal, lequel devient alors un journal "circulaire" (mode debug uniquement).
Documentation : mise à jour de la documentation en 1.9.5.

Mise à jour
Le crash ou boucle constaté a d'autant plus de chance de se produire qu'on ouvre beaucoup de fichiers.
Même si vous ne l'avez jamais constaté, il est plus prudent de faire la mise à jour.

A noter que le package standard ne comportant pas la fonctionnalité "DEBUG", vous n'avez pas la nouvelle fonctionnalité "journal circulaire" puisque elle n'est vraiment nécessaire que dans ce mode là. Cette fonctionnalité, si vous la souhaitez, nécessite donc que vous compiliez vous-même le package depuis le gitlab, et que vous lanciez le driver en mode verbosité 7 (--log-level 7)
L'aide (1fichierfs -h) n'indiquera pas la nouvelle fonctionnalité puisqu'elle n'est pas disponible hors DEBUG, par conte le "man" vous l'expliquera avec cette limitation.

Pistes futures (sans urgence) :
- Déprécier 16.04 et 18.04 qui nécessitent une fabrication particulière avec gnutls au lieu de openssl
- Regarder les nouvelles fonctionnalités de Fuse 3. Si elles présentent un intérêt pour 1fichierfs, les implémenter. En effet, en 24.04 Fuse 3 est le standard au lieu de Fuse 2 (toujours supporté)
- Améliorations diverses.

Pour Raspberry Pi, je vais désormais fournir le package 64 bits Bookworm. Pour Buster 32 bits, vous pouvez compiler depuis le source.

Raspberry Pi OS (Bookworm 64 bits): 1fichierfs_1.9.5~bookworm-1_arm64.deb

stat -c "%s %n" 1fichierfs_1.9.5~bookworm-1_arm64.deb; sha256sum 1fichierfs_1.9.5~bookworm-1_arm64.deb; md5sum 1fichierfs_1.9.5~bookworm-1_arm64.deb 
103404 1fichierfs_1.9.5~bookworm-1_arm64.deb
0d0efc83bd6957983764f5aa894c7152daebfaea7fe57b39add628972bbfe5bd  1fichierfs_1.9.5~bookworm-1_arm64.deb
b588cb71a14e81012257531109b82f17  1fichierfs_1.9.5~bookworm-1_arm64.deb

Dernière modification par Zakhar (Le 11/10/2024, à 08:52)

Zakhar · Le 10/10/2024, à 23:53

z3ndra a écrit :

salut, j'ai aussi remarqué un truc , c'est que 1fichierfs se met a consommer enormement de ressources cpu, ce qui freeze le serveur à la longue.

La nouvelle version devrait améliorer tout ça. N'oublie pas, après la mise à jour en 1.9.5 de faire un fusermount -u si le stockage distant était monté avant la mise à jour, puis monter à nouveau le stockage distant pour que la nouvelle version soit prise en compte.

Si tu vois d'autres bugs, n'hésite pas à prévenir, chez moi ça tourne sans aucune anomalie sur mon PC principal et mon Raspberry Pi depuis au moins 1 mois.

Dernière modification par Zakhar (Le 11/10/2024, à 08:53)

Zakhar · Le 24/10/2024, à 10:20

Dans les améliorations diverses, j'en ai 2 en tête :
- Permettre un téléchargement via Firefox directement sur le montage. Après examen, il semble que parfois firefox ferme le fichier local puis le réouvre pour continuer le téléchargement. Le mode "append" n'étant pas prévu pour le moment, cela échoue.
- Permettre à encfs de renommer un fichier. En effet, le renommage sur encfs provoque le changement de 8 octets en tête du fichier qui contient en gros la clé permettant de déchiffrer. Comme l'overwrite est interdit, cela ne fonctionne pas. J'ai en tête une "astuce" pour que cela soit possible dans la majorité des cas si un sous-répertoire est déclaré géré par encfs.

Dernière modification par Zakhar (Le 24/10/2024, à 15:17)

Zakhar · Le 19/01/2025, à 17:01

La modification pour encfs est faite.
Au passage correction d'un bug sur le "retry", et diverses améliorations de journalisation, et du test de non-regression qui ne testait pas vraiment le mode http (no ssl).

C'est en test sur mes machines, je rajoute quelques cas sur les tests de non-regression, et quand tout est OK un package.

C'est sans intérêt fondamental, sauf les bugs mineurs corrigés, si vous n'utilisez pas encfs par dessus le montage 1fichierfs.

Zakhar · Le 24/01/2025, à 19:06

En rajoutant la fonctionnalité encfs, j'ai découvert un bug sur la partie "write".

On peut le recréer de la sorte, créer un fichier de 4096 caractères ne contenant que des A, puis un fichier de 1024 ne contenant que des B :

$ printf "A%.0s" {1..4096} >fileA
$ printf "A%.0s" {1..1024} >fileB

Ensuite lancer la commande suivante sur votre montage :

$ cp fileA ~/1fichier/Divers/Test/file; dd if=fileB of=~/1fichier/Divers/Test/file bs=1024 count=1 conv=notrunc

-1) les deux commandes enchaînées vont (sans doute) fonctionner... alors que la seconde devrait échouer, la documentation précisant qu'on ne peut pas ré-écrire sur un fichier existant.
-2) On s'attend à avoir en résultat un fichier avec 1024 B au début puis le reste avec des A. C'est peut-être ce que vous verrez avec la cache du kernel, mais si vous "droppez" les caches, vous verrez en fait le fichier plein de A
-3) Une fois le cycle d'upload terminé (et éventuellement en "droppant" les caches), vous verrez (sans doute) le fichier attendu.

En réalité c'est peu fiable et ça peut créer des corruptions de fichiers parce que comme ce n'était pas prévu, l'écriture n'est pas "verrouillée" et on peut donc écrire des bouts d'un fichiers ou de l'autre.

La correction est faite. Le fonctionnement tel que décrit ci-dessus est pérennisé mais géré de façon "propre" c'est à dire avec le verrouillage adéquat. Cela permet notamment, quand on fait un rsync avec des petits fichiers (moins de 64K) sur une arborescence gérée par encfs, de ne pas avoir le "hack de renommage" sur ces fichiers là, ou au moins de tâcher de le limiter.

La test sur mes PC va donc prendre un peu plus de temps. En attendant, évitez les commandes comme celles montrées ci-dessus. Si vous ne faites que des écritures simples, comme par exemple une copie de fichier vers votre stockage, vous ne rentrez pas dans le cas de bug.

Dernière modification par Zakhar (Le 24/01/2025, à 19:07)

Zakhar · Le 23/02/2025, à 00:57

Encore un peu de patience !
1fichierfs s'étant planté au bout de plus de 15 jours d'usage quotidien sur mon Raspberry Pi, je vois un bug rare sur la fonction qui affecte les lectures aux "streams" (read_fits_stream). Il se produit quand un stream a un "gap" et reçoit une requête retardée et répétée pendant qu'il lit la suite.

Comme c'est une fonction centrale de l'algorithme, je vais tâcher de corriger avant de livrer les évolutions !
C'est aussi délicat à tester car le cas de bug se produit de façon très exceptionnelle et il n'y a aucune façon fiable de reproduire la séquence de lecture exacte qui provoque le bug rencontré.

En effet, en principe le kernel cachant les lectures ne répète pas les mêmes blocs de 4096. Cela peut bien sûr se produire en cas de pression sur la mémoire si une cache a dû être relâchée et qu'on a encore besoin des blocs antérieurs. Bref, cas rarissime mais pas inexistant, donc il faut tout de même corriger !

Dernière modification par Zakhar (Le 23/02/2025, à 01:06)

favancini · Le 07/07/2025, à 18:07

Salut,

Merci pour ton travail.

J'ai installé le logiciel sur un pc sous Ubuntu et j'ai pu monté mon stockage 1fichier très facilement.

Je voudrais utiliser ton logiciel sur mon NAS Qnap avec un cpu Intel x86

J'ai téléchargé "astreamfs-1.9.5.zip" depuis Gitlab

J'ai réglé plusieurs problèmes de dépendances et ensuite j'ai le message :

1fichier: line 219: astreamfs: command not found

Je ne sais pas comment régler le problème

Merci pour votre aide

Dernière modification par favancini (Le 07/07/2025, à 19:15)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#501 Le 13/09/2024, à 23:12

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

#502 Le 22/09/2024, à 13:12

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

#503 Le 26/09/2024, à 12:06

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

#504 Le 09/10/2024, à 23:25

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

#505 Le 10/10/2024, à 16:40

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

#506 Le 10/10/2024, à 23:53

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

#507 Le 24/10/2024, à 10:20

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

#508 Le 19/01/2025, à 17:01

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

#509 Le 24/01/2025, à 19:06

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

#510 Le 23/02/2025, à 00:57

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

#511 Le 07/07/2025, à 18:07

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

Pied de page des forums