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

Zakhar · Le 22/05/2019, à 17:32

(22 Mai 2019) Version 1.2.2

Nouveautés par rapport à la 1.2.1

Bug : le contenu des répertoires partagés s'affiche désormais correctement

Faut-il mettre à jour : si vous n'avez partagé aucun de vos répertoires 1fichier avec quelqu'un d'autre, la mise à jour n'a aucun intérêt pour vous. Ce bug existe depuis le début, c'est le "parsing" JSON qui est mal fait dans le cas où on a un "shares" dans le retour de l'API, provoquant un affichage aléatoire des fichiers du répertoire, et les sous-dossiers du dossier partagé ne sont jamais affichés.

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

Zakhar · Le 27/05/2019, à 14:26

jaxx21 a écrit :

Merci pour toutes ces belles infos.
Sinon, pour les statistiques, c'est qu'on y pense pas. Je pensais pas qu'on pouvait faire gérer ça aussi avec ton driver. ca fait des longs chiffres.Peut être qu'il y aura ensuite les Go ou Mo et les heures,min, ou sec.en tout cas, gros dossier encore.

Oui, c'est amélioré, voici ce que ça donne maintenant :

$ cat 1fichier/.stats
Uptime: 00:05:25

Readers:
     Down.  Nb. Req  Avg Time  Max Time   Ref  Qu  Nb. Err Speed Av.Sp
[00]  450M     3607    0.0201    2.9487 (   1)  2        0 35.3M 34.6M
[01]  141K       18    0.5087    2.7480  idle   0        0     0 20.1K
[02] 31.4M      272    0.0437    2.6544 (   2)  2        0 1.84M 1.12M
[03]  162K       19    0.4692    2.7382 (   2)  0        0     0 23.2K
----------------------------------------------------------------------
Tot.  482M     3916    0.0262    2.9487         4        0 37.1M 8.77M

API:
                        Nb. Req  Avg Time  Max Time Retry Nb. Err
folder/ls.cgi         :       4    0.1986    0.3255     0       0
download/get_token.cgi:       2    0.1412    0.1419     0       0
user/info.cgi         :       1    2.1307    2.1307     0       0
-----------------------------------------------------------------
Total                 :       7    0.4582    2.1307     0       0

Live streams:
  Ref   Size  Left Lnk Er Loc Stm Path
(   1) 34.9G 24:36   2      1   2 /.crypt/aFzSkQU-2euzGhZsYT7f0nNL/KOMpYD-smw9ihagHjrL9TUPLgMFSgWyzml2qIMvs34gsz5JDmu7YB8yswB3LmI8rd5A
(   2)  866M 25:02   3      1  12 /Vidéos/big_buck_bunny_1080p_stereo.ogg

Publication prochaine...

Dernière modification par Zakhar (Le 27/05/2019, à 15:43)

jaxx21 · Le 28/05/2019, à 10:45

Ha niquel,même le nombre de requête api. Merci

Zakhar · Le 28/05/2019, à 10:55

Et ça me permet de debugger les comportement anormaux aussi !

Il y avait un bug dans le "moteur" en cas de charge importante, et je vois des "optimisations" à faire pour le cas où on fait une copie, on abandonne, et on recommence.

Le "bug" ne corrompt pas les données, mais peut rendre parfois "Erreur d'entrée/sortie"... fâcheux !

... mais bon, il faudra que je pense à mettre aussi ma clé privée sur mon PC portable, parce que là je ne peux pas packager sans cela... donc ça va attendre quelques jours.

Dernière modification par Zakhar (Le 30/05/2019, à 20:57)

bingox · Le 03/06/2019, à 13:35

Bonjour , a propos de 1fichier , comment puis je savoir quels fichier sont dans le cold storage ? et y a t il un astuce pour ne pas avoir ses fichiers dans le cold storage (et peut etre supprimés !) ?

Zakhar · Le 03/06/2019, à 17:19

bingox a écrit :

Bonjour , a propos de 1fichier , comment puis je savoir quels fichier sont dans le cold storage ?

find 1fichier -type f -mtime +60

Va t'afficher la liste de tous les fichiers dans le "cold" de façon approximative, car l'algorithme de bascule en cold ne tourne qu'un fois par jour, à l'heure que tu récupères dans "info.cgi". La liste là est calculée à l'heure de la commande, et il y a donc potentiellement des fichiers qu'elle va t'indiquer "Cold" qui ne le sont pas, mais en gros tu peux calculer la taille ça tombe juste à quelques fichiers près.

bingox a écrit :

(et peut etre supprimés !) ?

Les fichiers dans le "cold" ne sont jamais supprimés tant que tu restes dans le quota. Au delà, il faut soit payer le quota supplémentaire, soit faire le ménage.
L'option de "suppression automatique" est entièrement à la main des utilisateurs, et permet précisément de faire le ménage plus facilement qu'à la main si on préfère la solution de suppression au paiement de l'espace supplémentaire utilisé.

Personnellement, j'ai déjà décidé que si je passe en "over-quota" (j'utilise comme sauvegarde de mes données personnelles), je payerai le quota supplémentaire parce que ça ne fait pas de sens de supprimer des sauvegardes !..
Le prix est très concurrentiel par rapport à l'achat et à la gestion de son propre support de stockage.

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

Zakhar · Le 03/06/2019, à 20:35

(3 Juin 2019) Version 1.3.1

Nouveautés par rapport à la 1.2.2

Bug : le driver pouvait dans certains cas renvoyer à tort "erreur d'entrée/sortie".
Optimisation : les "streams" ne sont conservés que 45 secondes (au lieu de 5 minutes). En réalité, au delà de la minute, la reprise sur un stream muet donne un temps d'attente inexplicable (y compris par la team 1fichier) d'une 20aine de secondes. Dans ces conditions, il est préférable d'ouvrir un nouveau stream ce qui met en général moins de 3 secondes. D'où le nouveau time-out.
Nouveautés : statistiques. Sur le même mode que le "refresh-file", vous pouvez déclarer un fichier statistiques et constater tout plein de choses à propos du fonctionnement du driver
Documentation : mise à jour pour détailler les statistiques.

Exemples pour les statistiques :

$ 1fichierfs --api-key=@~/.1fichier.key --stat-file=.stats ~/1fichier
$ cat ~/1fichier/.stats
Uptime: 01:10:19

Readers:
     Down. N.Req  Avg Time  Max Time   Ref  Qu N.Err Speed Av.Sp
[01]  206M  1659    0.0014    0.3175  idle   0     0     0  543K
[02] 69.2M   566    0.0014    0.1263  idle   0     0     0  616K
[03]  175M  1408    0.0040    2.1086  idle   0     0     0  513K
[04]  310M  2488    0.0007    0.1753 (   1)  1     0 1.04M  512K
----------------------------------------------------------------
Tot.  760M  6121    0.0017    2.1086         1     0 1.04M  532K

API:
                        N.Req  Avg Time  Max Time Retry N.Err
folder/ls.cgi         :    29    0.6655    2.3017     0     0
download/get_token.cgi:     3    0.1522    0.1563     0     0
user/info.cgi         :     2    1.1783    2.1851     0     1
--------------------------------------------------------------
Total                 :    34    0.6504    2.3017     0     1

         Trig. Timer   API Error   Total
Refresh:     0     2     0     0       2

             Number Memory
Allocations:  54901  8260K
Frees      :  54699  7822K
Difference :    202   438K

Live streams:
  Ref   Size  Left Lnk Er N.Loc N.Stm Path
(   1)  745M 12:47   2        2    17 /Vidéos/big_bucks_bunny.ogg
(   2) 2206M 00:00   0        1     2 /.crypt/I,-S6Q,wINReRoToGzQed,Eh/GyaC8v--Kxv-VsHLoFoZgMDl/ivEwsQqb8oPE4a5t8G24VxW4994MkrjvkeoRvgKcntfAJ,2zGYKU5z,,HU3TCd1tpLhTBrkN6DtTM9eCFf05zE5E

Vous pouvez aussi afficher les statistiques en permanence dans un terminal de la façon suivante (dans l'exemple avec rafraîchissement toutes les 3 secondes; CTRL+C pour terminer) :

$ watch -n3 cat ~/1fichier/.stats

Faut-il mettre à jour : Oui !
Même si vous ne comptez pas utiliser les statistiques, la mise à jour est conseillée. En effet, le bug corrigé risque de vous arriver si vous "chargez" un peu le driver en faisant des lectures en parallèle. Et c'est toujours stressant d'avoir "erreur d'entrée/sortie" quand on récupère une sauvegarde... même s'il y a toutes les chances que ça passe au deuxième coup quand vous "calmez" les accès en parallèle au driver.
Par ailleurs l'optimisation vous permettra par exemple de diminuer la cache de VLC de 30 secondes (mon réglage actuel pour éviter les "freeze" après une pause d'un film) à un truc plus raisonnable comme 5 secondes.

Dernière modification par Zakhar (Le 03/06/2019, à 20:56)

jaxx21 · Le 07/06/2019, à 10:26

Merci pour ce suivi et ce travail de fou !!! J'ai mis à jour pour ma part.

Dernière modification par jaxx21 (Le 07/06/2019, à 10:29)

Zakhar · Le 07/06/2019, à 16:59

jaxx21 a écrit :

Merci pour ce suivi et ce travail de fou !!! J'ai mis à jour pour ma part.

C'est pas fini, les statistiques ça prépare la partie "write" qui est encore plus "de fou" à cause du fait que côté serveur il n'ont pas fait grand chose pour aider au "write" !..

@Jaxx21 : sondage as-tu activé les statistiques en rajoutant à la commande de lancement --stat-file=stats (ou équivalent) ? En fait les statistiques, en dehors de debugger, pour la partie "read" c'est juste de la curiosité.

Dernière modification par Zakhar (Le 07/06/2019, à 17:01)

jaxx21 · Le 08/06/2019, à 08:52

@Jaxx21 : sondage as-tu activé les statistiques en rajoutant à la commande de lancement --stat-file=stats (ou équivalent) ? En fait les statistiques, en dehors de debugger, pour la partie "read" c'est juste de la curiosité.

Et bien moi , ma ligne de tout les jours est:

root@vps646287:~# 1fichierfs --api-key=XXXXXXXXXXXXXXXXXXXXXXXX -o allow_other /home/ubuntu/1fichier

et ca marche super pour mon plex.

ensuite, si j'ajoute ta commande:

1fichierfs --api-key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXX -o allow_other --stat-file=.stats /home/ubuntu/1fichier

il me met:

Segmentation fault (core dumped)

je dois pas mettre la bonne commande au bon endroit.

Zakhar · Le 08/06/2019, à 08:55

jaxx21 a écrit :

ensuite, si j'ajoute ta commande:
1fichierfs --api-key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXX -o allow_other --stat-file=.stats /home/ubuntu/1fichier
il me met:
Segmentation fault (core dumped)
je dois pas mettre la bonne commande au bon endroit.

Je vais regarder ça, peut-être une interférence avec allow_other. Tu es en quelle version d'ubuntu sur ton serveur ? 18.04 64 bits ?

(Pas besoin de debug... effectivement je le reproduis avec moins de paramètres que je n'utilise habituellement, je regarde ça !)

Dernière modification par Zakhar (Le 08/06/2019, à 09:03)

jaxx21 · Le 08/06/2019, à 09:05

Oui je suis sous Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-50-generic x86_64) (VPS de chez OVH)

et dans le debug.txt il y a:

[1fichierfs     0.000] NOTICE: started: Saturday  8 June 2019 at 10:03:10
[1fichierfs     0.000] NOTICE: successfuly parsed arguments.
[1fichierfs     0.000] INFO: log level is 7.
[1fichierfs     0.000] INFO: user_agent=1fichierfs/1.3.1
[1fichierfs     0.000] INFO: adding options=-orw,fsname=1fichier.com,subtype=1fichierfs
[1fichierfs     0.004] DEBUG: init_dir: `/` (id=0)
[1fichierfs     0.004] DEBUG: lock 999
[1fichierfs     0.004] INFO: <<< API(in) (iReq:1) folder/ls.cgi POST={"folder_id":0,"files":1} name=/
[1fichierfs     0.124] INFO: >>> API(out) (iReq:1) retry=0 json size=4009

Zakhar · Le 08/06/2019, à 09:06

Oui, j'ai vu ça, on ne passe même pas le listage de root, donc ce devrait être facile à débugger puisqu'à ce moment là on n'est pas encore en "multi-tâche" / daemon !

jaxx21 · Le 08/06/2019, à 09:08

Pas de soucis, prend ton temps. C'est impec ce que tu fourni et fonctionnel déja pour nous simples utilisateurs

Dernière modification par jaxx21 (Le 08/06/2019, à 09:09)

Zakhar · Le 08/06/2019, à 09:14

Huhu... "faute de frappe" dans le programme :

		if (f_r && r1 == t
			&& 0 == strncmp(val, params1f.refresh_file, r1)) {
			lprintf(LOG_WARNING,
				"refresh triggger off: a file or directory `/%s` already exists in `%s`.\n",
				params1f.refresh_file, d->name);
			*f_refresh = f_r = false;
		}
		if (f_s && r2 == t
			&& 0 == strncmp(val, params1f.refresh_file, r2)) {
			lprintf(LOG_WARNING,
				"statistics off: a file or directory `/%s` already exists in `%s`.\n",
				params1f.stat_file, d->name);
			*f_stat = f_s = false;
		}

Copier/coller abusif, dans le deuxième 'if' on s'intéresse au 'stat_file' or la comparaison (strncmp) est faite avec le "refresh_file". Ce qui veut dire que sans paramètre refresh_file, on tente d'accéder à un pointeur NULL...

Pas vu parce que j'ai toujours un refresh_file.

La correction est simple donc, ce sera relivré dans la journée. Si tu veux tester les statistiques, en attendant la correction, tu peux juste rajouter un refresh-file et ça marchera en contournant le bug.

--refresh-file=whatever

Merci du signalement.

P.S. : ça me fait penser qu'il faudrait que je rajoute un /TODO pour me constituer un jeu de test de cas divers.

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

jaxx21 · Le 08/06/2019, à 09:27

alors, je tape ma commande:

1fichierfs --api-key=XXXXXXXXXXXXXXXXXXXXXXX --stat-file=.stats --refresh-file=whatever -o allow_other /home/ubuntu/1fichier

et en effet, j'ai plus le bug et je vois bien un fichier stat dans le dossier 1fichier, et il contient:

Uptime: 00:03:13

Readers:
     Down. N.Req  Avg Time  Max Time   Ref  Qu N.Err Speed Av.Sp
[01]     0     0    0.0000    0.0000  idle   0     0     0     0
[02]     0     0    0.0000    0.0000  idle   0     0     0     0
[03]     0     0    0.0000    0.0000  idle   0     0     0     0
[04]     0     0    0.0000    0.0000  idle   0     0     0     0
----------------------------------------------------------------
Tot.     0     0    0.0000    0.0000         0     0     0     0

API:
                        N.Req  Avg Time  Max Time Retry N.Err
folder/ls.cgi         :     2    0.2116    0.3035     0     0
--------------------------------------------------------------
Total                 :     2    0.2116    0.3035     0     0

         Trig. Timer   API Error   Total
Refresh:     0     0     0     0       0

             Number Memory
Allocations:    159  1535K
Frees      :    153  1085K
Difference :      6   450K

Par contre, quand je tape ma commande:

watch -n3 cat ~/1fichier/.stats

j'ai:

Every 3,0s: cat /home/ubuntu/1fichier/.stats                                                                        vps646287: Sat Jun  8 10:27:07 2019

cat: /home/ubuntu/1fichier/.stats: No such file or directory

donc,j'ai peut être mal fait un truc.

Dernière modification par jaxx21 (Le 08/06/2019, à 09:29)

Zakhar · Le 08/06/2019, à 09:30

Oui parce que tu es en root.

Il faut donc remplacer par :

watch -n3 cat /home/ubuntu/1fichier/.stats

Explication : ~ est remplacé par le bash (interpréteur de commande) par le 'home' de l'utilisateur courant. Lorsque tu es en root, ton home est /root, et donc ~/1fichier/.stats devient /root/1fichier/.stats après le remplacement. Ce n'est pas ce que tu veux, puisque tu veux /home/ubuntu/1fichier/.stats

Et tant que tu ne fais rien avec le driver 1fichier, la seule chose qui va changer sera le uptime (temps écoulé depuis le démarrage) et la mémoire consommée (car les stats allouent/libèrent de la mémoire)
Ca devient intéressant quand tu utilises réellement de driver !

Tu verras alors la vitesse de download instantanée et moyenne, les noms de fichiers accédés, etc...

[Edit] : version corrigée (1.3.2) soumise au Launchpad pour Bionic (Xenial en cours), ce devrait être bon d'ici ~15 à 30 minutes.
[Edit 2] : Launchpad a terminé la compilation/packaging pour Bionic à 10h50, et à 11h02 pour Xenial.

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

Zakhar · Le 08/06/2019, à 09:50

(8 Juin 2019) Version 1.3.2

Nouveautés par rapport à la 1.3.1

Crash : signalement de Jaxx21 ci-dessus. Suite à un copier/coller abusif, le crash se produit systématiquement au démarrage lorsqu'on spécifie une fichier statistiques sans spécifier de fichier refresh.
Bug mineur : mauvais format pour la journalisation (log) des éventuelles erreurs de lecture. Par exemple, on 'log' 4294967291 au lieu de -5

Le crash ne se produit que si :
- vous spécifiez un fichier statistiques
- vous ne spécifiez pas de fichier refresh

Donc pour la mise à jour, c'est vous qui voyez selon votre usage !

@Jaxx21, tu peux retirer la partie refesh-file de la commande si tu n'en as pas besoin, le bug est corrigé et packages disponibles pour la MàJ

Dernière modification par Zakhar (Le 08/06/2019, à 10:13)

jaxx21 · Le 08/06/2019, à 10:13

Niquel, ca marche. Merci

Zakhar · Le 08/06/2019, à 10:15

jaxx21 a écrit :

Niquel, ca marche. Merci

Merci pour le signalement d'erreur, ça améliore la qualité du truc !

Zakhar · Le 08/06/2019, à 17:19

(8 Juin 2019) Version 1.4.0

Nouveautés par rapport à la 1.3.2

Nouveautés : rajout des options de curl --cacert et --insecure. La première option, avec le fichier de certificats adéquat (que vous pouvez télécharger sur le gitlab https://gitlab.com/BylonAkila/astreamfs … ier_ca.pem), permet de réduire notablement l'empreinte mémoire du programme. L'option --insecure réduit encore davantage, mais n'est pas conseillée pour des raisons évidentes !..
Améliorations mineures du code : rajout de l'option de compilation -pedantic et correction du code en rapport.

Faut-il mettre à jour : pas vraiment !

... sauf si votre machine est juste en mémoire, le gain procuré par l'option ne se verra pas. Dans le cas où votre machine a vraiment peu de mémoire et peine avec 1fichierfs plus les logiciels que vous utilisez, cela peut apporter un mieux.
Dans ce cas il vous faut soit récupérer le fichier de certificat (lien plus haut), soit le fabriquer ainsi :

openssl s_client -showcerts -servername 1fichier.com -connect 1fichier.com:443 >1fichier.pem

Dans le fichier créé : 1fichier.pem, repérez le premier bloc compris entre --- BEGIN CERTIFICATE --- et --- END CERTIFICATE --- et retirez tout le reste sauf ce bloc là (balises BEGIN et END doivent rester).

Ensuite vous rajoutez dans la commande de lancement :

--cacert=/path/to/1fichier.pem

Cela fait baisser environ de deux tiers (en moyenne) la consommation mémoire du programme. Il reste entre 30 et 50Mo au repos contre 90 à 150Mo avec le fichier de certificats par défaut que curl utilise.

Notez que la consommation mémoire n'est pas vraiment due à 1fichierfs lui-même ni à libcurl (les statistiques mémoire le prouvent, elles incluent les deux), mais à GnuTLS qui est assez gourmand, surtout avec le fichier de certificats par défaut (~250k au lieu de 2.5k pour le seul certificat utile). A noter également qu'OpenSSL n'est pas une option tant que la 16.04 est supporté car la version d'OpenSSL en 16.04 n'est pas "thread safe", donc non utilisable avec 1fichierfs.

Dernière modification par Zakhar (Le 08/06/2019, à 18:19)

xxx31fr · Le 08/06/2019, à 21:14

Hello @Zakhar,
C'est vraiment un super boulot ce que vous faites.
Je testerai votre application très prochainement.

Une petite question me trotte. Une fois que vous aurez implémenté la fonctionnalité de write, cela permettrait il d'utiliser le montage comme n'importe quel point de montage et donc, d'en faire un point de réception pour des torrent?

cordialement,

Zakhar · Le 08/06/2019, à 22:15

xxx31fr a écrit :

Hello @Zakhar,
C'est vraiment un super boulot ce que vous faites.
Je testerai votre application très prochainement.
Une petite question me trotte. Une fois que vous aurez implémenté la fonctionnalité de write, cela permettrait il d'utiliser le montage comme n'importe quel point de montage et donc, d'en faire un point de réception pour des torrent?
cordialement,

Pas tout de suite... et pas vraiment.
En réalité le protocole torrent provoque des écritures et des lectures aléatoires, et c'est précisément pour l'inverse qu'est optimisé le driver : pour les lectures séquentielles (stream), et dans un premier temps, il supportera uniquement l'écriture séquentielle, ce qui est la seule chose supportée par l'upload 1fichier.

L'écriture séquentielle est suffisante pour 95% des choses comme la copie, la sauvegarde, etc... et c'est donc ça qui sera implémenté en premier.
Un autre driver pas mal utilisé : curlftpfs (montage d'un ftp) supporte de même uniquement l'écriture séquentielle, puisque le protocole ftp ne supporte que cela grâce à "append".

L'écriture aléatoire ce sera dans un deuxième temps, mais pour être "raisonnable", elle nécessite un stockage temporaire local. Et du moment où on a un stockage local, le driver perd de son intérêt pour faire ce que vous imaginez !.. On peut simplement récupérer les torrent sur le stockage local et ensuite les uploader en une seule fois ce qui est une écriture séquentielle.
Comme par ailleurs le driver nécessite un PC allumé, ça ne transformera pas miraculeusement votre stockage 1fichier en seedbox ! ;-)

En lecture, c'est déjà un "montage standard", mais comme c'est expliqué dans le manuel :

man 1fichierfs

ce n'est pas du tout adapté à de l'accès aléatoire. On peut donc bien sûr stocker sur 1fichier l'iso de la dernière Ubuntu et le partager en torrent, ça marchera, mais avec de bien piètres performances et un gaspillage de bande passante flagrant à cause du type d'accès aléatoire de torrent... et encore une fois, il faut laisser le PC allumé pour ça, donc où est l'intérêt ? Ne vaut-il mieux pas récupérer l'iso en local et le partager ? Ca fait moins de 2Go, on a en général de quoi stocker ça localement...

... ou alors vous n'avez pas suffisamment détaillé le cas d'usage et j'ai mal compris !

Dernière modification par Zakhar (Le 08/06/2019, à 22:25)

xxx31fr · Le 09/06/2019, à 09:50

Bonjour @Zakhar,

Je vous remercie pour votre réponse.
Je pensais qu'il serait possible d'utiliser le montage 1fichier comme un disque local sdb avec les même fonctionnalités.
C'est aussi que dans ce sens là que je cherche à monter un stockage type google drive comme un "vrai disque" NAS ou USB pour permetttre aussi bien de l'écriture séqentielle que aléatoire sans stockage temporaire en local (surtout si le stockage local est très faible)

Cdlt

Zakhar · Le 09/06/2019, à 10:36

Oui, c'est un cas d'usage par exemple avec un Raspberry Pi.
Cela dit, vu le prix des clés USB en baisse constante, même si elles ne sont pas super performantes, ça fait un support temporaire pas cher pour un R-Pi. Personnellement j'ai acheté à vil prix une clé USB de 256Go pour la Freebox Mini. Du coup, il y a de quoi voir venir.

Mais hélas, aucun stockage à distance n'est fait pour l'écriture aléatoire, tout simplement parce que les protocoles web ne le prévoient pas, à part WebDAV qui est moribond.

La lecture aléatoire reste possible cependant, parce que depuis des décennies le http standard propose "range" qui permet de lire uniquement un morceau de la ressource. Mais 1fichierfs comme astreamfs dont il dérive, ne sont pas adaptés pour cela. Aussi, depuis la généralisation de https, faire des "range" isolés pour lire des bouts de fichier devient très "cher" en temps et ressource. En effet, cela nécessite un "handshake" SSL en plus de la requête, donc l'overhead est vite rédhibitoire en réalité.

Cependant, même si c'est lent (parce que pas optimisé pour ça) la lecture aléatoire reste fonctionnelle avec 1fichierfs ou astreamfs. Mais l'écriture est une autre paire de manche !..

Pour l'écriture, on a en réalité un problème plus fondamental de "synchro" si on veut être sûr d'écrire correctement via un réseau.

Imaginez la chose suivante :
Le client 1 envoit à 11:27:00.000 une requête A pour écrire entre 10 000 et 20 000
Le client 2 envoit à 11:27:00.050 une requête B pour écrire entre 15 000 et 25 000

Par le jeu des routages et des paquets IP qui se perdent, il se trouve que la requête B envoyée 50 millisecondes après, arrive avant la requête A sur le serveur.
Le résultat final ne sera alors pas ce qui est attendu dans l'ordre temporel absolu d'écriture.
Aussi, introduire un "numéro d'ordre" pour tenter de régler le problème ne fonctionne pas car il est impossible de synchroniser 2 machines via un réseau avec une probabilité de 100% (problème des deux généraux).
Le "numéro d'ordre" n'est possible qu'avec un client unique.
C'est pourquoi pour tenter de limiter ces corruptions WebDAV introduit les "verrous". Mais cela ne fait que déplacer le problème parce qu'on se trouve alors avec un problème de verrous orphelins lorsqu'un client qui a verrouillé est planté pour une raison quelconque. Et c'est aussi très moche d'un point de vue asynchronisme... les choses étant de plus en plus faites en parallèle.

La lecture n'a pas ce problème à l'évidence !..

Donc malheureusement, la seule issue réaliste à court terme pour l'écriture est d'avoir un support local : mémoire ou fichier par exemple, ou alors, bien sûr, d'écrire en séquentiel.

Dernière modification par Zakhar (Le 09/06/2019, à 10:46)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 22/05/2019, à 17:32

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

#102 Le 27/05/2019, à 14:26

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

#103 Le 28/05/2019, à 10:45

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

#104 Le 28/05/2019, à 10:55

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

#105 Le 03/06/2019, à 13:35

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

#106 Le 03/06/2019, à 17:19

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

#107 Le 03/06/2019, à 20:35

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

#108 Le 07/06/2019, à 10:26

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

#109 Le 07/06/2019, à 16:59

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

#110 Le 08/06/2019, à 08:52

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

#111 Le 08/06/2019, à 08:55

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

#112 Le 08/06/2019, à 09:05

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

#113 Le 08/06/2019, à 09:06

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

#114 Le 08/06/2019, à 09:08

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

#115 Le 08/06/2019, à 09:14

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

#116 Le 08/06/2019, à 09:27

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

#117 Le 08/06/2019, à 09:30

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

#118 Le 08/06/2019, à 09:50

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

#119 Le 08/06/2019, à 10:13

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

#120 Le 08/06/2019, à 10:15

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

#121 Le 08/06/2019, à 17:19

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

#122 Le 08/06/2019, à 21:14

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

#123 Le 08/06/2019, à 22:15

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

#124 Le 09/06/2019, à 09:50

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

#125 Le 09/06/2019, à 10:36

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

Pied de page des forums