ploopie a écritQuestion à 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 !
