Contenu | Rechercher | Menus

Annonce

DVD, clés USB et t-shirts Ubuntu-fr disponibles sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#326 Le 26/04/2021, à 22:21

Zakhar

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

Condamné en correctionnel, l'hebergeur 1fichier va faire appel.

Bon, en tout cas j'espère que ça ne va pas nous tuer notre excellent service de sauvegarde en ligne à un prix imbattable !..

Au moins 1fichierfs montre que ce genre de service est un outil. Comme toujours, ce n'est pas l'outil lui-même qui est illégal, mais l'usage que certains en font.

Comme le disent aussi les commentaires de l'article, il ne serait pas étonnant que tous les services de stockage en ligne, y compris ceux ayant pignon sur rue, hébergent plus ou moins de "fichiers partagés". roll

Dernière modification par Zakhar (Le 26/04/2021, à 22:24)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#327 Le 27/04/2021, à 00:17

lynn

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

Ben ça alors c'est surprenant ; des fichiers partagés illégalement sur 1fichier.com... qui l'eût cru ! tongue


«C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!»

Coluche

Hors ligne

#328 Le 27/04/2021, à 16:25

Zakhar

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

Je suis sûr qu'il y en a plein aussi qui sont partagés avec GDrive ou Onedrive, mais personne ne s'en émeut.

Il est bien parti le Cloud Européen avec les "z'ayant-droit-plein-de-soupe-mais-qui-en-veulent-toujours-plus" qui vont le détruire avant qu'il naisse. Pauvre Europe !..

Dernière modification par Zakhar (Le 27/04/2021, à 16:26)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#329 Le 17/05/2021, à 19:02

Zakhar

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

Brèves nouvelles.

Le "nouveau moteur de lecture" a bien avancé, il est déjà bien fonctionnel sur mes tests personnels.

Avantages : il ne nécessite pas de "threads séparés" pour la lecture, et il n'y a donc plus de limites à "4 threads de lecture" qui pouvaient donner des performances dégradées en cas de lectures en parallèle de beaucoup de fichiers. La limite à 4 "streams de lecture" est désormais par fichier, et se fait sans besoin de "threads séparés". Au final ça devrait prendre moins de ressources et donc être dans certains cas plus performant.

Inconvénients : c'est encore pour le moment "en travaux", même si ça marche déjà fort bien. Certaines choses ne sont pas encore ré-implémentées, notamment les statistiques qui vont changer assez radicalement.

Pour tester, pour les téméraires, ou si vous avez besoin de la fonctionnalité "beaucoup de lectures en parallèle", vous pouvez compiler directement depuis le Gitlab à partir de la branche "new_read_engine".

Evolutions : l'écriture suivra ensuite le même procédé (c'est plus simple en réalité pour l'écriture qui est moins "parallélisée") et la limite de 4 fichiers écrits en parallèle sera levée. J'ai commencé par la lecture, car si d'ici que je m'attaque à l'écriture, la Team 1fichier a mis son nouveau système envisagé (http pour les abonnés en écriture), je ferai d'une pierre deux coups.

Notez que la levée des limitations locales ne permet pas d'aller au delà des limites imposées par le service 1fichier.com (qui sont autour de 50 flux par IP en lecture... mais que je n'ai jamais atteintes !), et non plus, cela ne lève pas la limitation de la bande passante de votre connexion à internet ! big_smile

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


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#330 Le 03/06/2021, à 22:09

Zakhar

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

La mise au point de "nouveau moteur" de lecture m'a fait rendre compte que 1fichierfs est sous-optimisé pour des commandes de base comme cp (la copie simple).

Cette commande étant probablement une des plus ancienne de Unix-GNU/Linux, elle fait un truc qui est sans doute devenu totalement inutile avec les kernels moderne : de la copie "en parallèle" sur deux threads. Couplé avec le "read-ahead" du kernel, cela veut dire qu'on peut se retrouver à avoir 4 requêtes en cours sur un même "stream"... mais surtout que ces 4 requêtes peuvent arriver dans un désordre quelconque : les joies du parallélisme !
Or si j'avais bien prévu la gestion du "read-ahead" avec 2 requêtes inversées, ça ne va pas jusqu'à 4 !..

Cela se voit actuellement si vous faites un simple "cp" sur un gros fichier (par exemple pour récupérer sur vos disque locaux une "sauvegarde"), vous allez voir, en affichant les statistiques, que la lecture se fait bien séquentiellement, mais que de temps en temps, vous avez "de petits blocs" qui sont lus isolément. Résultat : pas totalement "optimisé" !..

Je travaille sur le "nouveau moteur" à gommer ça.

En attendant, au lieu d'utiliser "cp", je vous recommande l'excellent pv qui a aussi l'avantage de vous afficher une belle jauge de progression du transfert : avancement, vitesse, temps restant estimé...

La copie "à la souris", via "Nautilus" ne semble pas poser le même problème et se fait correctement.

Je testerai aussi le comportement face à rsync, qui est un outil "classique".

Enfin, toutes ces optimisations vont donner du sens à rajouter dans le "moteur" la lecture "splice" qui est sensée alléger la charge CPU et donc à défaut d'aller plus vite (c'est sans doute limité par votre fibre/ADSL ou CPU pour les flux chiffrés), consommera moins de ressources... donc quand même meilleures performance en cas de machine très chargée.

Je "benchmark" aussi avec une version de transfert "sans curl", parce que curl se comporte de façon qui me semble vraiment peu optimale quand on utilise les "pauses", ce que fait le nouvel algorithme. Je verrai si ça fait une différence visible, au moins en CPU, quand tout sera au point et donc vraiment comparable.

Encore un peu de patience donc pour les "améliorations". big_smile

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


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#331 Le 25/08/2021, à 21:50

NOLAK

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

Bonjour Zakhar,

Jusqu'à maintenant aucun problème mais aujourd'hui j'ai un souci.
Peux-tu m'aider ? Il impossible pour moi de remonter 1fichier, j'ai l'erreur la :

 ERROR: Ignoring: error 28 on curl_easy_perform url=`https://api.1fichier.com/v1/folder/ls.cgi` name=`/`.

Merci d'avance de ton aide.


J'ai finalement ma réponse :

1fichier a écrit :

Coupure totale du service cette nuit, déplacement des principaux serveurs.

Dernière modification par NOLAK (Le 26/08/2021, à 11:17)

Hors ligne

#332 Le 06/09/2021, à 10:42

Zakhar

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

Voila Nolak !

Effectivement, 1fichier.com a fait un grand changement d'architecture matérielle et logicielle. Le service a donc été coupé partiellement les jours précédents (certains machines "cassées") et pendant presque une journée le jour du changement.

Par conséquent, effectivement 1fichierfs ne se montait plus au démarrage... mais le site 1fichier.com ne répondait pas non plus, ce qui peut donner la puce à l'oreille que ça ne venait pas de 1fichiefs. tongue

(Et désolé de la réponse tardive, je n'ai pas eu l'e-mail de "suivi", mais puisque c'est résolu depuis que 1fichier.com fonctionne à nouveau, il n'y a pas de mal !)

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


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#333 Hier à 23:11

liberty_linux

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

Bonjour,
J'aime beaucoup le projet 1fichierfs! J'essayerai de le préparer pour le mettre sur le AUR de archlinux, car j'utilise plusieurs OS au quotidien. Pourrais-tu préciser la procédure pour compiler 1fichierfs et l'installer ?
Aussi, je me posais la questions, c'est parfois long d'attendre le traitement par 1fichier en FTP, serait-il possible d'implémenter une autre façon via le upload.cgi de l'API ?

Encore merci pour ton travail, c'est très pratique comme solution!

Hors ligne

#334 Hier à 23:51

Zakhar

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

Bonjour liberty_linux et merci pour tes encouragements.

La compilation est fort simple.
Il te faut tout d'abord les deux prérequis : fuse et curl

Pour Ubuntu on fait :

sudo apt install libfuse-dev libcurl4-openssl-dev

libcurl vient avec plusieurs ssl backends. Si ta version de openssl est supérieure à 1.1.0, il faut prendre celui indiqué dans la commande au dessus. Sinon il faut prendre gnutls pour des raisons de comparabilité multithread.

Bien sûr sur Arch, ce n'est pas apt le logiciel de package, je te laisse adapter !

Ensuite c'est très simple dans le répertoire principal du projet tu as un make, donc

make -B 1fichierfs

Cela suppose que tu as les outils standard make et gcc.. mais c'est tellement la base !..

Ensuite tu peux regarder ce que fait le package debian, il se contente de faire un

make install

Ce qui va copier l'exécutable dans /usr/bin, et les manuels au bon endroit : /usr/share/man/man1/ pour l'anglais et /usr/share/man/fr/man1/ pour le français.
En fait il y a sans doute un moyen pour "livrer" un man de façon plus "propre" que passer par le make, mais j'ai pas trouvé la documentation qui va bien... c'est une des difficultés du packaging sur Ubuntu/Debian, les docs sont merdiques et pas à jour... quand elle existent !


Pour le ftp hélas non il n'y a rien à faire pour le moment.
L'upload en http n'est pas possible car il faudrait connaître à l'avance la taille du fichier à uploader avec le fonctionnement actuel, et ce n'est pas une chose envisageable pour 1fichierfs parce que simplement fuse ne fonctionne pas ainsi !

On pourrait certes faire un code pour les "petits fichiers", genre moins de 64k, mais ça ferait tout un bout de code pour sans doute pas grand chose.

La vraie solution est dans les mains de la team 1fichier avec qui je parle de temps en temps.
Ils m'ont fait saliver sur la possibilité que les "premium" (c'est à dire nous les clients payants !) aient un upload http qui supporte le "chunked encoding".
Si c'est le cas, je peux remplacer presque du jour au lendemain l'upload en ftp par un upload en http-chunked-encoded, gagner les 5 minutes d'attente dues au FTP, et supprimer pas mal de code de la tâche de fond qui fait des choses en automatique.
Aussi tout le code de "reprise" devient totalement inutile et peut être simplement supprimé !

Cependant, cela ne supprimera pas la phase de "vérification" pendant laquelle le driver continuera de répondre que le fichier est occupé, puisque le serveur interdit la lecture tant que la vérification n'est pas finie.
Cette phase prend environ 15 secondes par giga, donc par exemple un fichier de 10Go est "indisponible" environ 2min 30.
Il est possible (et même plus que vraisemblable) qu'il y ait aussi en http, comme en ftp, un phase de "copie vers le storage". En fait quand on upload, on ne met pas directement les fichiers dans le "storage" mais dans un tampon intermédiaire, puis ensuite ils sont copiés vers le storage et détruits du tampon quand la copie est Ok. Cette phase prend à peu près le même temps que la phase "vérification".
Mais c'est sûr on y gagne par rapport à maintenant au moins les 5 minutes FTP...

Bref j'attends qu'1fichier fournisse cette "évolution", mais c'est très bas dans la liste de leurs priorités hélas !

Par contre si tu viens de copier un gros fichier via 1fichierfs, tu peux couper ton PC, et la fois d'après que tu l'allumeras, le fameux code de reprise se chargera de finir le travail en déplaçant le fichier uploadé au bon endroit. Evidemment si tu attends la fichier sur l'interface web, il ne faut pas faire ça. En effet 1fichierfs upload tous ses fichiers dans le répertoire .upload-1fichierfs situé à la racine de ton compte, et les fichiers n'ont pas leur "vrai" nom. Tout ça c'est pour le mécanisme de reprise !

En attendant, j'ai toujours en perspective le "nettoyage" du "moteur" de lecture. Le "moteur" actuel est un peu bancal même s'il marche globalement bien. J'ai des "race conditions" connues à l'ouverture simultanée de plusieurs fichiers qui peuvent donner des erreurs de lecture. Si cela arrive, il faut juste redémarrer le driver. C'est tellement rare que je n'ose toucher le code de faire plus de mal que de bien, et j'attends plutôt la "version propre" en travaux.
Le "moteur" de lecture actuel n'a aussi "pas assez de buffers" par rapport à ce que fait Linux sur une "copie séquentielle". En réalité, le kernel et les outils GNU travaillent parfois avec jusqu'à 4 buffers de 128k d'avance ou de retard. Il faut donc 3 buffers de 128k de stockage, si on veut qu'une copie séquentielle soit bien aussi séquentielle pour 1fichierfs. Actuellement le moteur ne travaille qu'avec un seul buffer de 128k. Cela ne produit pas d'erreur, mais juste parfois une "sous-optimisation" parce que le moteur devra faire plusieurs requêtes (range) au lieu d'une seule qui aurait suffi dans le code idéal !
J'avais testé une voie pour le ré-écrire, mais cette voie s'avère être un impasse. La "bonne architecture" est ce qui est fait actuellement, c'est à dire lecture via un thread "reader"... il faut juste que je le rendre "propre" et généralisable à d'autres APIs ou par exemple au générique astreamfs qui fonctionne sur le simple http(s).

Dernière modification par Zakhar (Aujourd'hui à 00:06)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne