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

Zakhar · Le 22/11/2019, à 17:04

(22 Novembre 2019) Version 1.5.4

Nouveautés par rapport à la 1.5.3

Amélioration : l'algorithme de récupération du lien de téléchargement est plus solide, il devrait dans la plupart des cas trouver une solution et résoudre ce que Ploopie signalait ci-dessous.

ploopie a écrit :

PS: je te laisse aussi un petit log dans mon syslog juste pour avoir ton feedback, mais j’imagine que c’est un ratelimit coté 1fichier?

Nov  3 00:34:59 host 1fichierfs: [1fichierfs  6310.019] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/download/get_token.cgi` name=`https://1fichier.com/?itrq69j0bv7wk4`.
Nov  3 00:34:59 host 1fichierfs: [1fichierfs  6310.019] ERROR: http_code 403 on get_token json resp.:`{"status":"KO","message":"Excess slots #897"}` for https://1fichier.com/?itrq69j0bv7wk4

Notes :
En pratique, les fonctionnalités comme "indexer une grande série de fichiers" qui peuvent être déclenchées (Plex, Kodi, rythmbox, Shotwell, etc...) par vos lecteurs de médias devraient fonctionner quel que soit le nombre de fichier à indexer. Pour cela, l'algorithme a besoin que soit paramétré sur votre compte 1fichier la fonction "Identification Réseau" (dans les "Paramètres" de votre compte). Cela consiste à indiquer l'IP depuis laquelle vous utilisez 1fichierfs... et il vous faut alors bien sûr une IP fixe (et que vous n'ayez pas besoin de la fonction pour une autre machine, car on ne peut déclarer qu'une seule IP). Le programme utilisera automatiquement le mode "secours" avec cette "identification réseau" lorsqu'il en aura besoin. Si l'utilisation n'est pas possible, les fichiers seront simplement inaccessibles "comme avant" lorsque l'API qui distribue les tokens est en erreur. A noter que le mode "de secours" est un peu plus lent, donc 1fichierfs tâchera de revenir au mode standard en testant de temps en temps si l'API de récupération du lien de téléchargement fonctionne à nouveau.

Faut-il mettre à jour : oui, recommandé
- Outre l'amélioration signalée, l'algorithme d'obtention du lien de téléchargement est aussi plus solide sur d'autres aspects et notamment fait un "retry" s'il y avait un déphasage d'horloge sur la durée du token (cela peut être provoqué par exemple si le PC est mis en veille).
- L'algorithme précédent avait également un comportement non-atomique qui aurait pu (théoriquement) déclencher des effets bizarres.

Raspberry Pi (Raspbian Buster 32 bits): 1fichierfs_1.5.4~buster-1_armhf.deb (taille : 59304 octets)

Checksums:

$ sha256sum 1fichierfs_1.5.4~buster-1_armhf.deb 
429ef5d816f99fdc1c03c3379d375c4096223bcea6110cacfc561e87459061de  1fichierfs_1.5.4~buster-1_armhf.deb
$ md5sum 1fichierfs_1.5.4~buster-1_armhf.deb
04a5904caa1c91b5d17ff34654a358ac  1fichierfs_1.5.4~buster-1_armhf.deb

Dernière modification par Zakhar (Le 22/11/2019, à 17:52)

lynn · Le 22/11/2019, à 17:40

Zakhar a écrit :

(22 Novembre 2019) Version 1.5.4
Nouveautés par rapport à la 1.5.4

Nouveautés par rapport à la 1.5.3

Zakhar · Le 22/11/2019, à 17:49

C'est bien, il y en a qui suivent ! Merci, c'est corrigé.

Mode écriture on the way maintenant !..

lynn · Le 22/11/2019, à 17:50

C'est toujours pas bon

Zakhar · Le 22/11/2019, à 17:52

Oui, c'était même pire, j'ai modifié le mauvais... là ça doit être Ok, désolé !

lynn · Le 22/11/2019, à 17:57

Là, c'est tout bon !

Zakhar · Le 22/11/2019, à 18:11

L'essentiel c'est que ce soit "tout bon" sur le package aussi (il a tourné quelques jours chez moi sans bug) ! N'hésitez pas à signaler des bugs ou des fonctionnalités qui vous semblent manquer.

Zakhar · Le 24/11/2019, à 18:59

(24 Novembre 2019) Version 1.5.5

Nouveautés par rapport à la 1.5.4

Amélioration : les statistiques affichent les contentions (tentatives d'accès à la mémoire en parallèle échouée).
Bug : les calculs de temps étaient faux (surestimés) dans les statistiques -erreur de signe sur la retenue !-.
Bug important (engine) : dans certains cas (au début d'un fichier) on réutilisait le buffer interne sur lui même provoquant une boucle infinie (100% CPU).
Bug important (engine) : dans certains cas d'agencement de buffers à lire on provoquait un double lock dans le même thread provoquant un blocage du programme.
Bug important rare (engine) : dans certains cas d'agencement très particulier (inversion + retard) on pouvait provoquer une lecture infinie du même "range".
Amélioration : meilleur logging en mode debug.

Mise à jour plus que recommandée !
Notez que vous n'avez peut-être jamais rencontré les bugs en questions car il se manifestent si on sollicite beaucoup le driver. En l'occurrence j'ai fait 4 shell qui comparaient 2 fichiers stockés sur le cloud, chaque shell fait 500 fichiers différents et le fichier de comparaison est identique. Cela fait 4 flux différents, plus 4 flux sur le même fichier, le tout en parallèle sur mon Raspberry Pi qui est un peu plus lent que le PC de bureau, donc les bugs de parallélisme se voient mieux.
Après les corrections ci-dessus, tout passe bien. J'avais déjà constaté le 1er bug (boucle et 100% CPU) une seule fois sur mon PC portable.

Dans la mesure ou les bugs corrigés concernent "engine", c'est à dire le cœur du moteur de téléchargement, je vous conseille la mise à jour !

Le bug de statistiques est cosmétique, et pas grave si vous n'utilisiez pas les statistiques. Les temps d'appel d'API étaient surestimés à cause d'une erreur de retenue dans le calcul !..

Raspberry Pi (Raspbian Buster 32 bits): 1fichierfs_1.5.5~buster-1_armhf.deb (taille : 59608 octets)

Checksums:

$ sha256sum 1fichierfs_1.5.5~buster-1_armhf.deb
327180709d050e2b76ae13ea0671ed1373289a2d1e084844f0e84d2106aeb71a  1fichierfs_1.5.5~buster-1_armhf.deb
$ md5sum 1fichierfs_1.5.5~buster-1_armhf.deb
fd34b6c939040968ef8e269e0431110d  1fichierfs_1.5.5~buster-1_armhf.deb

Dernière modification par Zakhar (Le 24/11/2019, à 19:04)

Zakhar · Le 03/12/2019, à 22:34

Quelques nouvelles sur le mode écriture.

Pour continuer dans la philosophie de 1fichierfs, il n'y a rien de spécial à rajouter sur la ligne de commande pour pouvoir écrire : c'est tout automatique, et ça ne nécessite absolument AUCUN espace disque local temporaire !
L'empreinte mémoire supplémentaire est un buffer de 512K, plus un programme un peu plus volumineux.

En pratique, et contrairement à d'autres outils comme rclone, ça veut dire que vous pouvez utiliser votre Raspberry PI avec sa carte SD de 8Go pour traiter des fichiers aussi gros que les reap de vos BluRay, aussi bien en lecture qu'en écriture.

Le principe est que 1fichierfs utilise son propre sous-compte FTP pour uploader les fichiers, afin de ne pas se prendre les pieds dans le tapis avec ce que vous feriez "manuellement" sur le site web vous-mêmes. Aussi, cela obligerait à donner votre mot de passe FTP à 1fichierfs ce que je ne souhaite pas !
Donc 1fichierfs crée un sous-compte FTP astucieusement nommé "1fichierfs" et qui utilise la clé d'API que vous lui avez déjà donnée en mot de passe. L'upload de ce sous-compte FTP se fait vers /.upload.1fichierfs

Pour l'instant ces valeurs sont "en dur" (dans des variables) dans le programme. Si vous n'aimez pas le nom du répertoire d'upload ou que le sous-compte ftp s'appelle 1fichierfs, je peux rendre ça paramétrable par des options... mais pour l'instant il y a d'autres priorités !
La limitation est aussi que si vous avez déjà utilisé vos 10 sous-comptes FTP possibles... eh bien c'est pas de chance, l'écriture ne sera pas possible sans les options pour désigner le sous-compte à utiliser avec son mot de passe.

Avancement
L'écriture de fichiers fonctionne, c'est à dire que le transfert en FTP se fait bien, avec des performances correctes, et il supporte même des écriture depuis des outils comme encfs qui vous permettent de chiffrer vos données personnelles, or il faut savoir que même en écrivant en séquentiel (copie par exemple) encfs ne fait pas tout à fait du séquentiel, mais va ré-écrire à certains moments.

Pour l'instant le fichier écrit arrive donc sur le serveur FTP.

Il reste à faire le "post traitement". Cela consiste à :
- attendre 5 minutes ("amélioration" demandée à la team 1fichier qui l'a mis dans la //TODO list mais sans engagement)
- déclencher le stockage ("amélioration" demandée et aussi sur la //TODO list, car à ce jour l'API permet uniquement un déclenchement "global" qui va traiter tous les fichiers de tous les sous-comptes et ceux que l'utilisateur a mis lui-même, on veut éviter d'interférer avec l'utilisateur en ne demandant le stockage que du sous-compte ou que de certains fichiers nommés).
- attendre que le fichier arrive sur le stockage: ce qui prend un temps variable dépendant essentiellement de la taille du fichier -prévisible- et probablement de la charge des serveurs -non prévisible-
- l'attente se fait en regardant "de temps en temps", si c'est arrivé sur le répertoire d'upload FTP
- une fois arrivé à bon port, il reste à déplacer/renommer le fichier là où l'utilisateur voulait qu'il soit.
- A partir de là le fichier est sur le stockage, il ne reste plus qu'à faire un "refresh" automatique pour que l'utilisateur puisse le lire depuis le stockage "cloud" à la prochaine fois qu'il accédera au répertoire où est le fichier.

Nice to have (fioritures) : le mode "reprise".
En effet, comme il faut un certain temps entre le moment où vous avez fini d'écrire le fichier (en FTP) et le moment où celui-ci est stocké à sa place (le temps du "post-traitement"), si vous éteignez votre PC avant que le post-traitement soit terminé, le fichier va soit rester sur le serveur FTP (et être effacé en 24h), soit être dans le répertoire d'upload, mais on ne sait pas où on doit le mettre ensuite.
Pour cette deuxième partie, on peut faire quelque chose à partir du driver.
Pour les 5 minutes, il n'y a hélas rien à faire tant que la team 1fichier n'a pas codé les "améliorations" si vous laissez passer plus de 24h et que vous n'êtes pas en mode "FTP automatique".

Et bien sûr, les statistiques pour l'écriture... c'est un must pour voir si les fichiers sont bien arrivés !

Dernière modification par Zakhar (Le 03/12/2019, à 23:10)

ploopie · Le 08/12/2019, à 16:42

Hello @Zakhar merci pour toutes ces avancées, notamment le root-path, très pratique.
Je test également rclone avec le backend cache qui semble apporter de meilleurs résultats notamment pour un Plex.

Il intègre aussi l'écriture et, contrairement à 1fichierfs, je n'ai jamais rencontré l'erreur plus haut (http_code 403).

Zakhar · Le 08/12/2019, à 16:56

Merci pour ton intérêt Ploopie.

Oui, j'ai fait un comparatif plus haut avec rclone.

L'erreur 403 que tu as rencontrée est désormais corrigée (de la même façon que fait rclone ). Version du 22 novembre... mais prends plutôt celle du 24 novembre elle corrige certains crash potentiels. Si tu as mis le dépôt (PPA), et que tu as fais un "apt update/upgrade", en principe tu es déjà à jour de la 1.5.5

En résumé rclone est plus polyvalent (plusieurs could services, plusieurs O.S.) mais beaucoup plus gourmand en ressources. En gros il est 5 fois plus gourmand, et beaucoup beaucoup plus (une infinité !) en stockage local puisque 1fichierfs n'en demande aucun.

Utiliser un stockage local, d'ailleurs un peu comme cela se passe avec une Linux Live (même si le "stockage" en question est un disque RAM) possède bien sûr ses avantages... et ses inconvénients.
Sur un Raspberry Pi par exemple, je suis content d'avoir 1fichierfs parce que l'usage d'un stockage local est à proscrire : ça tuerait la carte SD en moins de rien, et aussi l'espace est tout petit... même pas l'équivalent d'un film HD ;-)
Après on peut bien sûr rajouter des disques externes, surtout avec l'USB 3 du RPi 4, mais plus on en rajoute, plus la consommation monte et ce n'est pas ce qu'on cherche avec une machine sobre comme celle là.

Bien sûr, le fait que rclone consomme plus de ressources n'a strictement aucune importance s'il s'agit d'un PC qui tourne en permanence à 10% de CPU... Dans ce cas, le PC sera toujours assez puissant et ce n'est pas le CPU qui va bloquer. Et comme pour faire tourner Plex, surtout en mode ré-encodage de vidéo à la volée, il faut une bête de course, en pratique sur ce genre de machine la différence ne se ressent pas.

Pour 1fichierfs, la partie écriture est en bonne voie.

Je suis actuellement sur la "branche write" du programme, et cela fonctionne unitairement. Hier j'ai stocké ainsi 3 fichiers chiffrés, c'est à dire avec empilement de 1fichierfs + encfs, tout cela avec zéro stockage local temporaire, et en faisant une simple copie.

C'est encore un peu "brut" pour que je vous livre une première version "write". J'ai encore un peu de travail pour boucler les crash potentiel qu'un utilisateur impatient pourrait créer, et il y a sans doute encore des bugs avec des comportements "normaux" comme copier plusieurs fichiers en parallèle (si, si, ça doit marcher aussi si on fait ça !).
Il faut imaginer des scenarii du genre : je lance une écriture d'un fichier, et pendant que ça copie, j'efface la destination ! (si, si, ça fonctionne parfaitement sur Linux grâce au RCU du kernel)
Ou alors : je renomme le fichier pendant que le driver est en train d'attendre qu'il soit en place sur le stockage, ça met 5 minutes -temps FTP- + ~30sec + 13,7 sec par giga. Plein de temps pour que l'utilisateur fasse des choses bizarres !

Il y aussi le cas où l'utilisateur éteint le PC alors que le process de stockage n'est pas fini ou qu'on attend pour FTP. Pour ce cas là j'ai demandé une amélioration à la team 1fichier... mais pas de date d'engagement.
Si ça tarde je ferai un "contournement".

Bref, dès que j'ai une version au moins "bêta" qui permet d'écrire, je vous mets ça en ligne.

Dernière modification par Zakhar (Le 08/12/2019, à 17:36)

ploopie · Le 10/12/2019, à 18:02

Merci pour ton retour, je continue(rais) d'utiliser 1fichierfs pour le besoin dont tu parles (pas de stockage local) mais je pense aussi que pour un PC dédié à Plex (ce que j'ai) rclone est effectivement un meilleur choix car le stockage local n'est pas un problème

Je continue bien sur de remonter des soucis et à suivre le fil

Zakhar · Le 16/12/2019, à 21:48

ploopie a écrit :

Je continue bien sur de remonter des soucis et à suivre le fil

Cool !

Un petit avancement : l'écriture marche du feu de dieu sur ma version en développement. Mais je viens de découvrir une autre phase où le fichier uploadé est visible sur le répertoire destination, mais n'est pas encore disponible (le serveur fait des vérifications : antivirus, somme de contrôle ou que sais-je encore !...)

On est en train de mettre au point un message clair pour distinguer ça presque en direct avec la team 1fichier. On vient d'arriver à un message clair... mais la clarification avait bloqué le processus. On va y arriver !

Une fois ceci fait, je pourrai faire une première release pour le "write". Il restera ensuite encore pas mal de peaufinage, mais la release 1.6.0 vous permettra de faire d'éventuels retours, et corriger les bugs éventuels (et certains !) en même temps que le peaufinage.

En tout cas c'est très cool de pouvoir traiter des fichiers de la taille d'un BluRay (autour de 50Go) sur un Raspberry Pi avec seulement une carte SD de 16Go.

Dernière modification par Zakhar (Le 16/12/2019, à 21:52)

Zakhar · Le 17/12/2019, à 22:37

(17 Décembre 2019) Version 1.6.0

Nouveautés par rapport à la 1.5.5

NOUVEAU: l'écriture ! : avec les limitations classiques de FTP et le processus de mise en ligne du serveur, vous pouvez désormais aussi copier vos fichiers vers votre cloud 1fichier simplement avec votre navigateur de fichiers.
Changement : pour limiter l'empreinte mémoire, les messages de debug ne sont plus inclus dans le package. Il est donc limité aux message de niveau "info". Pour les messages debug, il faut construire l'exécutable à partir du source avec l'option DEBUG=1.

Mise à jour: c'est une première version avec l'écriture, elle est donc susceptible d'avoir des bugs de jeunesse, surtout sur la partie écriture.

D'ailleurs, par précaution et pour que vous ne soyez pas bloqué, je vous mets les .deb de la version précédente (que vous trouvez sur mon ppa)

1fichierfs_1.5.5~Xenial-1_amd64.deb
1fichierfs_1.5.5~Xenial-1_i386.deb
1fichierfs_1.5.5~Bionic-1_amd64.deb
1fichierfs_1.5.5~Bionic-1_i386.deb

Si vous avez un problème bloquant avec la nouvelle version, vous pouvez récupérer le .deb correspondant à votre version et faire :

sudo  dpkg -i nom_du_package.deb

Fonctionnement : pour faire simple... vous n'avez absolument rien à rajouter à la commande pour pouvoir écrire. 1fichierfs va s'occuper de tout avec des options par défaut "raisonnables".
Notamment il va créer un compte FTP pour uploader avec le préfixe : 1fichierfs- suivi d'une chaîne de caractère calculée à partir de la nanoseconde afin que l'identifiant FTP soit raisonnablement unique.
L'upload de fichier se fera vers le répertoire .upload.1fichierfs

L'upload suit la procédure qui est définie sur 1fichier.com, c'est à dire :

vous copiez le fichier
une fois la copie terminée, il faut attendre 5 minutes que l'automatisme FTP se déclenche si votre compte est en automatique, mais dans tous les cas le programme déclenchera pour le cas où vous êtes en "manuel".
le serveur procède alors au stockage, c'est à dire déplace le fichier depuis les serveurs FTP vers le répertoire d'upload spécifié. Cela prend "un certain temps", de l'ordre de 2 minutes 30 secondes pour 10Go par exemple.
ensuite le fichier arrive sur le répertoire d'upload, 1fichierfs le met exactement à l'endroit où vous l'avez copié, avec le nom que vous lui avez donné.
à partir de là le fichier est sur votre stockage, mais n'est pas encore tout à fait prêt. Le serveur fait encore des choses (qui le regardent, comme vérifier la somme de contrôle du fichier) et va "libérer" le fichier au bout d'un temps à peu près équivalent à celui du stockage.

Pendant tout ce processus, le fichier n'est pas accessible en lecture, à l'exception de la phase de copie où j'ai fait en sorte de donner un peu de marge à certains programmes utiles comme encfs... mais la lecture est limitée à une fenêtre de quelque kilo-octets par rapport à la fin du fichier où on écrit.

Cette inaccessibilité du fichier en lecture est une limitation du serveur (et c'est à peu près pareil sur tous les stockages)... et n'est contournable qu'avec utilisation d'espace disque local ce qui n'est pas la direction que je veux donner à 1fichierfs (utilisez rclone si vous avez plein de disque local !)

Pendant cette phase d'upload, si vous accédez au fichier en lecture, vous aurez une erreur parlante : "Device or resource busy".

Autre détail pendant cette phase d'upload:

le fichier est toujours visible dans l'arborescence avec sa taille qui va évoluer en cours de copie.
vous pouvez à tout moment, aussi bien pendant la copie que pendant que le serveur travaille, renommer et déplacer le fichier.
vous ne pouvez pas (pour le moment, c'est un /todo pour la suite) supprimer le fichier pendant le processus, sauf si c'est un fichier vide. Pendant la toute dernière phase où le serveur vérifie le fichier, la suppression devient possible même si vous ne pouvez pas lire le fichier.
vous ne pouvez pas faire une "copie" (en réalité un lien dur) pendant ce processus (ça n'a pas trop de sens de faire cela en réalité !).

ATTENTION :
Comme le processus d'upload, au delà de la copie du fichier lui-même prend un peu de temps (7 à 8 minutes pour 10Go), si vous coupez 1fichierfs pendant ce temps là, les fichiers risquent d'être perdus. Vous aurez un message d'avertissement dans la log. C'est comme arracher une clé USB avant que l'écriture soit finie... sauf que là il faut attendre un peu plus. Désolé, limitation serveur !
J'ai cependant demandé à 1fichier une amélioration de cela en faisant une suggestion plus adaptée à un fonctionnement API. Si cela traîne un peu trop, je ferai un contournement qui tâchera de récupérer les fichiers au démarrage suivant de 1fichierfs. En attendant, comme avec vos clés USB, un peu de patience pendant que le processus d'écriture se déroule !

Usage particulier : si vous compter utiliser plusieurs instances de 1fichierfs sur le même compte, il faut leur spécifier un nom FTP unique sinon la dernière lancée va casser l'upload des autres. Cela se spécifie avec l'option --ftp-user
Vous avez aussi l'option --no-write qui a pour effet de ne pas lancer les fonctions d'écriture, et vous vous retrouvez donc comme en version 1.5.5.

Raspberry Pi (Raspbian Buster 32 bits): 1fichierfs_1.6.0~buster-1_armhf.deb (taille : 65820 octets)

Checksums:

$ sha256sum 1fichierfs_1.6.0~buster-1_armhf.deb
af9b3314c5dce55350d6596e8a72c39efa08c4585b6b1a8743d9ae76658631fa  1fichierfs_1.6.0~buster-1_armhf.deb
$ md5sum 1fichierfs_1.6.0~buster-1_armhf.deb
b4459c4e39b85412dbff2f50fcc1e7fa  1fichierfs_1.6.0~buster-1_armhf.deb

Dernière modification par Zakhar (Le 25/12/2019, à 20:15)

Zakhar · Le 11/01/2020, à 15:14

Quelques performances en jouant avec le driver depuis un seul PC :

Download
Down

Débit down

Upload

Débit Up

Les débit théoriques de la Freebox (fibre) sont 125Mo/s en down et 75Mo/s en up.

Mon PC étant relié à la Freebox en Ethernet 1Gbps, le débit théorique sur un seul PC est également de 125Mo/s. C'est à dire qu'on arrive davantage à "saturer" la Freebox en faisant le test depuis plusieurs machines en parallèle... mais bon là en down on arrive à 124,4Mo/s sur un théorique de 125Mo/s sur un seul lien !

Les flux de test sont de simples copies ou comparaisons de fichiers.

Dernière modification par Zakhar (Le 11/01/2020, à 15:31)

ploopie · Le 20/01/2020, à 21:32

Question à deux balles : pourquoi avec rclone on peut copier des fichiers à la volée (dispo instantanée dans 1fichier) et avec 1fichierfs il faut passer par le FTP et tout le process qui va avec et que tu décris ?

Zakhar · Le 20/01/2020, à 22:20

ploopie a écrit :

Question à deux balles : pourquoi avec rclone on peut copier des fichiers à la volée (dispo instantanée dans 1fichier) et avec 1fichierfs il faut passer par le FTP et tout le process qui va avec et que tu décris ?

C'est juste que rclone n'a jamais documenté comment ça se passe réellement.

J'ai testé ce W.E. avec des fichiers de taille différente dont un de 45Go (pour simuler un truc genre BluRay), seule la phase de 5 minutes est différente entre 1fichier et rclone, et cette attente de 5 minute est arbitraire et sera un jour enlevée par la team 1fichier.

1fichierfs utilise FTP, rclone utilise HTTP.

Donc prenons l'exemple d'un fichier de 45Go que tu récupères sur le web (ailleurs que 1fichier, sinon une copie de lien prend 2 secondes) et que tu veux mettre sur ton stockage. En l'occurrence il s'agissait de plusieurs fichiers "rar" sur mes deux Freebox accédés avec astreamfs, le programme "père" de 1fichierfs. Voici les temps :

Unrar / Copie locale : 25 min (Supposant limité à 30Mo/s, vitesse Freebox) identique copie locale préalable pour rclone et pour 1fichierfs unrar directement sur FTP (le temps réseau disparaît donc dans le parallélisme)
Upload : 15 min (fibre Free, upload moyen 50Mo/s) uniquement rclone car il peut pas uploader avant la fin de la phase 1 ne connaissant pas la taille totale, 1fichierfs fait l'upload directement pendant le unrar et en parallèle
Attente FTP : 5 min (contrainte actuelle serveur) uniquement 1fichierfs contrainte serveur actuelle sur FTP -va disparaître un jour-
Stockage : 12 min (FTP vers stockage ou HTTP vers stockage) identique car temps "copie serveur"
Vérification : 12 min (vérification du checksum) identique car temps "vérifications serveur"

Donc en gros, l'opération prend 54 minutes avec 1fichierfs et 64 minutes avec rclone (en supposant la machine suffisamment rapide pour rclone qui est nettement plus gourmand en ressources !).

Dans ce cas là, 1fichierfs est plus rapide malgré les 5 minutes d'attente FTP, car il peut faire lecture réseau (download) et écriture réseau (upload) sans avoir à passer d'abord par une écriture locale sur le disque du fichier en entier, chose que rclone ne peut pas faire par construction puisqu'il utilise HTTP pour uploader.
Dans la logique "streaming" héritée de astreamfs, FTP est donc bien plus adapté que HTTP.

Lorsque la team 1fichier aura "optimisé FTP", l'API pourra sauter les 5 minutes d'attente et donc 1fichierfs sera plus rapide que rclone sans conteste (pas de copie préalable), mais comme il n'utilise pas de disque local, pas d'accès en lecture le temps de l'upload.

En effet, comme rclone utilise http, il est obligé de connaître la taille totale avant de commencer à uploader, et donc de faire une première opération de copie sur le disque local.
Dans notre cas, rclone va donc "consommer" 45Go de "cache" qui est en réalité de l'espace disque local. Si c'est un SSD ça l'use car il n'a qu'un nombre limité d'écritures, sans aller plus vite car la première phase de l'exemple est limitée par le download.

Ensuite évidemment, l'avantage est que les données étant en local sur le disque, on peut y accéder immédiatement en lecture.

C'est donc un cas d'usage différent :
- besoin d'accéder tout de suite, suffisamment d'espace local => rclone
- pas d'accès immédiat (au moins pendant les 45 minutes de l'opération), pas de consommation d'espace => 1fichierfs

Bien sûr, sur les copies de "petits" fichiers (collection de musique, de photos), l'attente actuelle de 5 minutes est assez handicapante... espérons qu'elle va bientôt être supprimée, la team 1fichier l'a bien dans sa liste de courses, mais en "non urgent". Cependant, j'ai fait l'expansion d'un iso où j'avais stocké tous mes reap de CD, en réalité la différence de 5 minutes n'est que sur le total de l'opération. Il suffit de lancer la copie en bloc, et l'attente se fait sur la liste globale. On n'attend évidemment pas que le premier fichier soit complètement stocké pour écrire le deuxième !.. D'ailleurs 1fichierfs peut même uploader 4 flux en parallèle (codage en #define dans le programme). L'attente dans le process d'upload n'a pas de limite en nombre de fichiers, elle est juste limitée par la mémoire de la machine !

Et dans les sophistications amusantes (prochaine version 1.6.2 qui sera packagée dans les jours à venir), essaye voir de supprimer ou renommer un fichier avec rclone pendant que tu es en train d'écrire pour voir comment ça se passe ! ;-)

Et pour être moins "méchant" essaye un renommage/déplacement pendant la phase de "stockage serveur" pour voir comment ça se passe sur rclone. Ça m'étonnerait qu'ils aient prévu ce cas de parallélisme !..

Avec 1fichierfs, ça se passe bien, et même sans locks, merci le RCU.

Et puis 1fichierfs a des statistiques... aussi en écriture dans la version prochaine. C'est quand même trop classe, mais plaisanterie mise à part, fort utile pour vérifier que le process de stockage est bien terminé sur tous les fichiers.
Je ne sais pas si rclone fait cela. Si par exemple tu as bien fait la copie locale, mais tu arrêtes la machine pendant la phase upload (2 ci-dessus), le process est cassé. Certes comme tu as une copie locale en cache rien n'est perdu... mais c'est de la "cache", donc susceptible d'être effacé si tu mets d'autres fichiers !

Bref, il n'y a de toute façon pas d'outil "meilleur dans l'absolu", il y a des cas d'usage et des outils plus ou moins adaptés à ton usage !

A noter que mes programmes ont souvent pour but de gagner du temps en évitant les copies locales (comme ne le fait pas rclone dans ce cas).
J'ai cité les différents "rar" sur mes Freebox, astreamfs permet de monter ces fichiers depuis les 2 freebox, pour faire le unrar, et ce sans avoir à copier au préalable les "rar" en local. Ensuite 1fichierfs enchaîne en copiant directement ça sur 1fichier.com sans passer par le disque local.
Le truc "optimisé" passe donc de la Freebox directement à 1fichier.com sans aucun octet écrit sur un support local.
Le truc "pas optimisé" va commencer à copier les "rar" (45Go), faire le unrar en local (re-45Go) et ensuite uploader. Donc en plus des temps réseau, tu payes 90Go de lecture/écriture sur disque... que je suis très content d'éviter !

Dernière modification par Zakhar (Le 20/01/2020, à 23:18)

Zakhar · Le 21/01/2020, à 10:20

ploopie a écrit :

Question à deux balles : pourquoi avec rclone on peut copier des fichiers à la volée (dispo instantanée dans 1fichier) et avec 1fichierfs il faut passer par le FTP et tout le process qui va avec et que tu décris ?

Indépendamment de la réponse précédente, on peut répondre :

- en réalité l'utilisateur n'a pas à s'en préoccuper, il copie le fichier et il le voit sur l’arborescence immédiatement (vrai également pour 1fichierfs).

Cependant, comme pour une clé USB, cela n'est qu'une vision rendue par le logiciel, et en réalité la "copie n'est pas terminée".

Les utilisateurs le savent très bien pour les clés USB. Si on copie un gros fichier et immédiatement quand le système dit "c'est terminé" on arrache la clé... en réalité ça va mal se passer. C'est pourquoi il est recommandé de "démonter/éjecter la clé", là on peut avoir un message "Attendez avant de retirer la clé" puis un moment après "C'est bon vous pouvez retirer la clé".

Pour la copie vers un "cloud storage" comme 1fichier.com, c'est exactement pareil.

Si je vous ai expliqué tout le détail, c'est juste une question de transparence (dans la veine de l'Open Source), mais le détail importe peu en réalité, et il y a des phases "critiques" dans la sauvegarde vers le cloud, que l'on utilise 1fichierfs ou rclone.

Pour 1fichierfs vous avez un outil (ça vient !) qui vous permet, comme les clés USB, de savoir s'il est Ok ou pas de démonter 1fichierfs (ou éteindre votre PC), cet outil ce sont les statistiques.

Pour rclone... c'est à vous de deviner quand c'est Ok (à moins que j'aie loupé un outil).

La "disponibilité immédiate" est aussi rendue par 1fichierfs. Quand vous copier un fichier, vous le voyez tout de suite dans l’arborescence qui est montée, et sa taille évolue au fil de la copie.
Par contre, ni pour 1fichier, ni pour rclone, vous ne voyez ce même fichier dans votre page web "Mes Fichiers" sur le site 1fichier.com. Précisément, pour rclone vous ne voyez absolument rien, pour 1fichierfs vous pouvez constater, en vous branchant sur le serveur FTP, que le fichier est bien en cours d'upload.

La différence est que rclone copie le fichier sur un disque local, et donc à ce point il est accessible en lecture (depuis le support local), tandis que 1fichierfs envoie directement en FTP. Le fichier en cours de copie est alors visible sur le serveur FTP (en utilisant Filezilla par exemple). Seulement, 1fichier.com a bloqué la lecture des fichiers uploadés en FTP, et donc même si on voit le fichier sur le serveur (FTP), on ne peut pas rendre la fonctionnalité de lecture qui a été bloquée.

Aussi, rclone a fait un boulot assez remarquable de "factorisation" entre tous les fournisseurs de stockage distant. Il supporte tout un tas de fournisseurs, mais du coup c'est du "plus petit commun dénominateur", et ça ne va pas dans les détails d'implémentation de 1fichier.com aussi loin que 1fichierfs. Mais je tire mon chapeau, ça rend les fonctions essentielles avec environ 200 lignes de code alors que 1fichierfs tourne autour de 10 000 lignes de code. La comparaison est cependant biaisée ainsi, car les ~200 lignes de rclone ne sont que la partie spécifique à 1fichier, il faudrait aussi compte tout le code commun pour gérer un stockage distant, tandis que dans 1fichierfs les 10 000 lignes comprennent le code qui pourrait être mis en facteur et tout ce qui est spécifique (la séparation n'est pas faite aussi bien car pas utile pour le moment !).

Dernière modification par Zakhar (Le 21/01/2020, à 10:25)

Zakhar · Le 21/01/2020, à 14:46

(21 Janvier 2020) Version 1.6.2

Nouveautés par rapport à la 1.6.0

NOUVEAU: statistiques d'écriture : outre que c'est classe, l'intérêt essentiel des statistiques et de vous permettre de déterminer s'il est sans risque d'éteindre votre PC ou pas, c'est à dire, comme pour une clé USB, si tout est bien stocké sur le serveur. A partir du moment où plus aucun fichier n'est dans la liste "Write", c'est le signal que tout va bien ! A noter que la liste peut présenter des fichiers vides (taille 0) ceux-là ne seront jamais mis sur le serveur car il ne supporte pas des fichiers de taille 0, donc s'il y a seulement cela sur la liste, tout est Ok.
Changement : l'option pour ne pas lancer tout le process d'écriture s'appelle désormais --no-upload, et ce pour éviter la confusion avec -o ro ou -o rw.
Améliorations : désormais, déplacer/renommer ainsi que supprimer est possible à tout moment pendant le processus d'écriture (y compris pendant qu'on écrit sur le fichier !).
Améliorations : nouvelles entrées fuse permettant de changer la date, les droits ou le propriétaire d'un fichier. Ces entrées ne font absolument rien puisque ce n'est pas géré par le stockage distant, mais ont juste le mérite que des utilitaires classiques comme cp (copie) ne vont pas vous mettre un message d'avertissement vous disant : "Je ne peux pas changer les droits du fichier !".
Corrections : nombreuses corrections de bugs sur la partie write qui est désormais suffisamment stable pour ce nouveau packaging.
Documentation : mise à jour de l'aide et du manuel.

Mise à jour: c'est une version bien plus stable pour l'écriture que la précédente. Elle apporte aussi les statistiques d'écriture qui vous permettent d'éteindre en toute sécurité votre PC après avoir vérifié que les écritures sont bien terminées. Donc si vous utilisez l'écriture (upload), il est plus que recommandé de faire la mise à jour.

Raspberry Pi (Raspbian Buster 32 bits): 1fichierfs_1.6.2~buster-1_armhf.deb (taille : 71600 octets)

Checksums:

$ sha256sum 1fichierfs_1.6.2~buster-1_armhf.deb 
a40ea4dcb5215ce94b8a1e52297d67ce606dc1ad475725bb654ba6c1f252687c  1fichierfs_1.6.2~buster-1_armhf.deb
$ md5sum 1fichierfs_1.6.2~buster-1_armhf.deb 
061617c5846fd1682bf337f9cfa3c9f4  1fichierfs_1.6.2~buster-1_armhf.deb

TODO list (points principaux)

(GIT) Maintenant que c'est suffisamment stable, "merger" la branche "write" et intégrer le pull request sur gitlab.
Implémenter "truncate" (à zéro). Sans cela, pour écrire par dessus un fichier (en le remplaçant), il faut commencer par le supprimer. Ce n'est donc pas bloquant mais utile. Certaines commandes s'en servent implicitement (comme pv).
Mécanisme de "reprise" permettant de ne pas "égarer" de fichiers en cas de coupure prématurée du PC (ou démontage du programme). Les fichiers seront "récupérés" (si possible) au démarrage suivant.
Optimisation (invisible si votre PC est assez puissant) pour éviter la double copie en cas d'écritures en gros blocs
Réviser la gestion de permissions
Implémenter des time-outs et des "retry" en cas de plantage réseau download/upload.

Clarifications
Les explications données dans les posts précédents quant à la façon dont l'écriture se produit sont données "à titre éducatif" et pour une totale transparence "open source".
Comme cela est essentiellement lié à la façon dont fonctionne le serveur (1fichier.com), il n'est rien que 1fichierfs (ou tout autre outil comme rclone) puisse faire pour changer fondamentalement les choses !

... en fait pas tout à fait... j'ai fait une suggestion d'amélioration à la team 1fichier qui l'a acceptée. Cela va permettre de gagner 5 minutes sur le cycle d'upload, ce qui est surtout appréciable pour les petits fichiers. Comme il s'agit d'une "suggestion" elle est dans la liste de choses à faire de la team 1fichier avec aucun critère d'urgence. Il faut donc être patient.

D'un point de vue "utilisateur", au delà de parfaire sa "connaissance informatique" (en comprenant comment les choses fonctionnent), tout cela n'est pas indispensable à connaître.

Il suffit juste de savoir que le processus de stockage (upload) prend "un certain temps", et que comme une clé USB, pour des raisons "techniques"(*), il ne faut pas "couper" la machine pendant ce processus. Pour cela les statistiques vous permettent de constater que plus rien n'est dans la liste d'écriture (hormis des fichiers vides) et qu'il est donc possible d'éteindre la machine (ou démonter 1fichierfs) sans risque.

A noter que la durée du processus d'upload pourrait être plus longue avec rclone (à cause du choix d'écrire d'abord sur le disque local) et que le risque de "perte" existe également (pas à cause des mêmes raisons), car il est inhérent au fonctionnement du serveur.

Dans les deux cas (1fichierfs et rclone) lorsque vous copiez un fichier depuis votre PC sur le montage 1fichier, vous le verrez immédiatement dans arborescence via le logiciel (1fichierfs ou rclone). Par contre, si en même temps vous regardez la page web "Mes fichiers" de votre compte 1fichier.com, vous ne verrez absolument aucune trace de ce fichier au moment de la copie. C'est normal, et identique dans les deux logiciels !.. En réalité ces deux logiciels "simulent" localement une certaine arborescence de fichiers (ce qui est le cas de tout driver fuse !).
Compte tenu des implémentations différentes, comme rclone a besoin d'espace disque (inconvénient) pour copier en premier le fichier en local avant de commencer l'upload (inconvénient), ces choix présentent un côté positif (avantage) c'est que le fichier est toujours accessible en lecture... normal puisqu'il est sur votre disque local (du moins tant qu'il n'est pas plus gros que la zone de "cache" que vous avez allouée).
1fichierfs a fait les choix inverses d'être peu exigeant en ressources et notamment de réclamer absolument zéro stockage local, y compris pour l'écriture (upload). L'upload peut ainsi commencer en parallèle dès les premiers octets copiés, et se fait directement sur 1fichier.com sans passer par la copie locale. A contrario de cet avantage, et par contrainte serveur, le fichier écrit n'est pas disponible en lecture tant que le processus d'upload n'est pas achevé. Les statistiques vous informent à ce sujet.

(*) j'adore le terme "technique" en tant que geek, surtout prononcé par "monsieur tout le monde". En gros ça veut dire : il y sans doute d'excellentes raisons, mais je ne veux surtout pas essayer de comprendre ni m'y intéresser, d'autres sont là pour ça ! Donc en réalité c'est un terme tout relatif, il dépend essentiellement du fait que vous vouliez ou pas vous intéresser à une chose, et par exemple en "comprendre son fonctionnement", comme l'un des 4 piliers du "libre" vous y autorise.

Dernière modification par Zakhar (Le 21/01/2020, à 16:11)

ploopie · Le 21/01/2020, à 17:57

Et bah dis donc, ça m'a fait de la lecture après le boulot mais j'ai appris des choses, merci

Rclone offre aussi l'avantage d'uploader directement sur le dossier souhaité contrairement à 1fichierfs, non ?

Zakhar · Le 21/01/2020, à 18:25

ploopie a écrit :

Et bah dis donc, ça m'a fait de la lecture après le boulot mais j'ai appris des choses, merci

Parfait, les explications étaient "à but éducatif", donc si tu as appris des choses c'est que le but est atteint !

ploopie a écrit :

Rclone offre aussi l'avantage d'uploader directement sur le dossier souhaité contrairement à 1fichierfs, non ?

Oui et non !
Le fonctionnement serveur est différent entre upload http et upload ftp, car il est calqué sur les manipulations qu'un utilisateur ferait "à la main", c'est à dire en utilisant son navigateur (upload http) ou un utilitaire tel filezilla (upload ftp).

Dans le cas de ftp, le "répertoire d'upload" est paramétré dans les paramètres du compte. Quand tu manipules "à la main" et un fichier à la fois, tu peux très bien aller changer ce répertoire d'uplaod avant de lancer le transfert FTP, et ainsi le fichier se retrouve "au bon endroit directement". Tu peux aussi très bien ne pas le faire, tout regrouper dans un répertoire d'upload, et faire les déplacement/renommage une fois que les fichiers sont arrivés dans le répertoire commun d'upload. Le résultat final est le même. Ce deuxième fonctionnement est le choix de 1fichierfs car c'est plus "propre". 1fichierfs se réserve un répertoire pour ses upload (actuellement en dur : /.upload.1fichierfs) ainsi ce que fait le driver n'est pas mélangé avec les manipulations "à la main" de l'utilisateur. Le "renommage/déplacement" final est fait automatiquement par 1fichierfs, donc même si c'est "techniquement" en deux étapes, au final c'est pareil pour l'utilisateur.

Maintenant http fonctionne différemment. Lorsque tu vas sur les pages web de 1fichier.com pour uploader un fichier, tu dis avant de commencer où tu veux que le fichier soit stocké. Donc cela apparaît comme "une étape" mais en réalité cela crée des inconvénients suggérés dans les posts précédents.

Prenons le cas du "déplacement" du fichier. Tu as commencé une copie d'un gros fichier vers un répertoire "Musique". En réalité tu t'aperçois que "ton doigt a rippé" et que tu n'as pas cliqué sur le bon répertoire cible, tu voulais mettre le fichier dans "Vidéos".

1fichierfs : aucun problème, même pendant que la copie est en cours tu peux "renommer/déplacer" le fichier !.. Pas besoin d'interrompre la copie, effacer et recommencer, c'est donc tout bon !..
Explication "technique" : en réalité l'endroit cible où se trouve le fichier est juste une indication qui sera utilisée à la toute fin du processus quand il s'agira de déplacer le fichier depuis le répertoire commun d'upload vers l'endroit où l'utilisateur souhaite poser le fichier. Donc si on change d'avis après le démarrage de la copie ce n'est pas grave, c'est juste cette indication de destination qui change !.. Lorsque le fichier est arrivé sur le répertoire upload, on utilise alors le dernier emplacement que l'utilisateur a spécifié, peu importe qu'il ait changé 10 fois d'avis pendant le temps du processus. La vision via le logiciel prend tout de suite en compte le "changement d'avis", et si on regarde avec le gestionnaire de fichiers on verra donc que le fichier en cours de copie vient de passer "magiquement" du répertoire "Musique" à "Vidéos"... alors qu'en réalité son nom FTP n'a pas changé, et sa cible première est toujours bien le répertoire d'upload !

rclone : ça m'étonnerait qu'ils aient prévu le cas !.. Fais le test et dis nous ce que ça donne. Si tu renommes pendant la copie, il y a des chances que ça ait été bloqué et que tu ne puisses pas le faire et que la seule façon soit de couper la copie, effacer et recommencer. Si toutefois ça marchait, rclone se retrouverait dans ce cas à égalité avec 1fichierfs. En effet, comme tu ne peux pas changer d'avis quant à la cible d'un fichier uploadé en http, il faudrait attendre que le fichier arrive dans le premier répertoire désigné pour ensuite le déplacer vers la "bonne cible". Ca m'étonnerait beaucoup qu'ils aient prévu ce traitement...
Aussi dans ce cas l'inconvénient est que si tu arrêtes la machine au moment critique (transfert http vers storage) tu vas te retrouver avec des fichiers dans "Musique" qui n'ont rien à y faire, tandis qu'avec 1fichierfs, la "pollution" reste dans le répertoire d'upload spécifique.

Pouvoir donner le nom du répertoire cible avant le transfert présente cependant un avantage en cas de "coupure prématurée" du PC, c'est à dire pendant la phase de transfert vers le "storage".
En effet, dans ce cas, et si tu n'a pas changé d'avis (renommage/déplacement ou suppression) tu peux couper le PC sans attendre.

Cela sera réalisé dans une version future par 1fichierfs par la fonction "reprise".
Comment cela va fonctionner "techniquement" : de petits fichiers indiquant la cible d'un upload seront rajoutés dans le répertoire upload général. Si le PC est coupé pendant les phases critiques, au prochain redémarrage le programme utilisera les indications dans ces petits fichiers pour "terminer le travail".
Comme expliqué ci-dessus, pouvoir donner la cible avant le démarrage de la copie a certes un avantage, mais ne dispense pas de la fonction reprise à cause des phases où le fichier devient complètement invisible (copie ftp/http vers storage). Donc puisque la "reprise" est de toute façon indispensable et rend la fonctionnalité, autant ne pas "polluer" l'arborescence utilisateur avec des fichiers qui n'ont pas lieu d'y être.
Aussi j'avais demandé à l'équipe 1fichier de pouvoir spécifier cela dans un "traitement FTP", mais j'ai simplifié la demande car finalement je trouve que c'est n'est pas nécessaire et même présente des côtés négatifs qui m'ennuieraient.

Dernière modification par Zakhar (Le 21/01/2020, à 18:39)

Zakhar · Le 29/02/2020, à 17:08

Quelque news :
Voila, la fonction "resume" (reprise) est implémentée (première implémentation).

Cela permet, une fois que vous avez copié un fichier, de couper 1fichierfs (ou la machine) si vous avez envie. A supposer que votre compte soit en FTP automatique (recommandé) la prochaine fois que vous relancerez 1fichierfs celui-ci fera le "resume" qui consiste à terminer le processus d'upload en plaçant le fichier uploadé au bon endroit, avec le bon nom.

Au passage il y a eu quelques améliorations, notamment la prise en comptes de caractères interdits dans les noms de fichier (pour l'API), la gestion des caractères "spéciaux" (0x01 à 0x1F) et de la longueur maxi des noms de fichiers.
Aussi correction d'un bug sur le pipe d'écriture qui provoquait un crash à la fin d'une écriture selon la taille finale du fichier écrit.

En test sur mes machines, si tout va bien ce sera packagé sous une quinzaine de jours.

Dernière modification par Zakhar (Le 29/02/2020, à 23:28)

Zakhar · Le 07/03/2020, à 15:05

(7 Mars 2020) Version 1.6.5

Nouveautés par rapport à la 1.6.2

NOUVEAU: reprise du processus d'upload : si vous n'avez pas le temps d'attendre après avoir copié un fichier, vous pouvez désormais couper le PC et le reste des étapes d'upload sera fait au démarrage suivant. Magique non... et toujours avec la même ligne de commande minimale !..
Nouvelles options : --dry-run pour voir les états de reprise, et --resume-delay=temps pour reprendre y compris les fichiers récents (moins de 15 min).
Améliorations : protection pour ne pas écrire dans le répertoire d'upload (on peut par contre supprimer et "sortir" des fichiers de ce répertoire).
Documentation : mise à jour de l'aide et du manuel.

Mise à jour: si vous uploadez souvent des fichiers sur votre espace, il est commode d'avoir la fonction "reprise" et donc de faire la mise à jour. Dans le cas contraire, c'est vous qui voyez !

Raspberry Pi (Raspbian Buster 32 bits): 1fichierfs_1.6.5~buster-1_armhf.deb (taille : 76244 octets)

Checksums:

$ sha256sum 1fichierfs_1.6.5~buster-1_armhf.deb 
e3fad5b737e16e2a1377d766a22860e8efb231037662eb0020490d913e170a25  1fichierfs_1.6.5~buster-1_armhf.deb
$ md5sum 1fichierfs_1.6.5~buster-1_armhf.deb
eb03b0f701babfbc6f1910442b3b1ff9  1fichierfs_1.6.5~buster-1_armhf.deb

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

Zakhar · Le 07/03/2020, à 15:19

Annonce : je considère la version de ce jour, 1.6.5, comme "complète", c'est à dire contenant toutes les fonctionnalités nécessaires à un bon fonctionnement.

Ça ne veut pas dire que j'arrête le développement bien sûr, mais juste qu'il n'y a pas d'autre fonctionnalité que j'estime essentielle à rajouter (dans ce qui est faisable avec la philosophie de 1fichierfs et les possibilités du serveur) !

Si vous signalez des bugs, ou si vous demandez des fonctions intéressantes (comme la dernière fonction demandée par Ploopie), je corrigerai ou ferai évoluer.

Pour le reste, ce sera des "optimisations", par exemple un meilleur "moteur" de lecture est sans doute possible et pourrait aussi bénéficier à astreamfs. L'écriture peut aussi être optimisée pour certains cas. On peut aussi éviter les requêtes d'API unitaires en gardant les connexions ouvertes (un certain temps) pour accélérer en évitant le handshake TLS.
J'ai laissé tomber certaines fonctions comme "truncate", car le faire proprement aurait nécessité trop de ré-écriture du code. Le gain était de toute façon faible car seul truncate à zéro est possible, et l'utilisateur peut le faire simplement en 2 phases : 1- supprimer le fichier, 2- écrire (avec le nom du fichier effacé en 1).
Et bien sûr, on peut toujours améliorer et bien mieux documenter le code.

Mais pour l'essentiel, je considère que tout est fait, en conservant la même philosophie :

aucun besoin de ressources disque locale (idéal pour manipuler des fichiers de 30 à 50Go sur un Raspberry Pi sans support disque ajouté !)
toujours avec la ligne de commande minimale initiale : 1fichierfs Point_de_montage (bien sûr il est pratique d'ajouter au moins la clé d'API en paramètre pour éviter de la taper à chaque fois !)
ça démarre toujours en moins d'une seconde, parce que toutes les dernières nouveautés se font "en tâche de fond". La seule exception est si vous mettez un "remote root" qui oblige à descendre plusieurs niveaux d’arborescence... mais là on ne peut guère faire mieux !

Amusez-vous bien avec votre stockage 1fichier !

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

lynn · Le 07/03/2020, à 15:56

Zakhar a écrit :

Nouveautés par rapport à la 1.6.5

Par rapport à la 1.6.2 plus certainement...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#201 Le 22/11/2019, à 17:04

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

#202 Le 22/11/2019, à 17:40

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

#203 Le 22/11/2019, à 17:49

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

#204 Le 22/11/2019, à 17:50

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

#205 Le 22/11/2019, à 17:52

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

#206 Le 22/11/2019, à 17:57

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

#207 Le 22/11/2019, à 18:11

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

#208 Le 24/11/2019, à 18:59

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

#209 Le 03/12/2019, à 22:34

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

#210 Le 08/12/2019, à 16:42

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

#211 Le 08/12/2019, à 16:56

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

#212 Le 10/12/2019, à 18:02

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

#213 Le 16/12/2019, à 21:48

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

#214 Le 17/12/2019, à 22:37

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

#215 Le 11/01/2020, à 15:14

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

#216 Le 20/01/2020, à 21:32

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

#217 Le 20/01/2020, à 22:20

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

#218 Le 21/01/2020, à 10:20

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

#219 Le 21/01/2020, à 14:46

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

#220 Le 21/01/2020, à 17:57

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

#221 Le 21/01/2020, à 18:25

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

#222 Le 29/02/2020, à 17:08

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

#223 Le 07/03/2020, à 15:05

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

#224 Le 07/03/2020, à 15:19

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

#225 Le 07/03/2020, à 15:56

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

Pied de page des forums