Aller au contenu

Acces Disque Toutes Les 5 Secondes

CoolRaoul

Par CoolRaoul
dans Cloud Station Server

 Partager

Messages recommandés

CoolRaoul Community Regular

CoolRaoul

Posté(e)
Posté(e) (modifié)

Salut à tous,

Ca faisait longtemps que j'avais remarqué que mon NAS laissait entendre une activité disque à intervalles réguliers à toute heure du jour et de la nuit.

J'ai enfin pris un peu de temps pour essayer de comprendre la cause du phénomène.

Me suis cross compilé un exemplaire de inotify-tools et je pense avoir mis le doigt sur la source de ce comportement:

fserv>  inotifywait -m -r --timef "%H:%M:%S" --format "%T %f %e" /volume2/@cloudstation/@sync
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
09:38:12 syncfolder-db.sqlite ACCESS
09:38:17 syncfolder-db.sqlite ACCESS
09:38:22 syncfolder-db.sqlite ACCESS
etc ...

Et le coupable est ...

fserv> lsof /volume2/@cloudstation/@sync/syncfolder-db.sqlite
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
syncd   11220 root   12u   REG    9,3  4787200 1441796 /volume2/@cloudstation/@sync/syncfolder-db.sqlite

On constate que le process syncd (fait partie de cloudstation) fait un acces à "syncfolder-db.sqlite" toutes les 5 secondes.

En grattant un peu plus avant ça se confirme:

fserv> strace -e read,access -fp 11220
Process 11220 attached with 8 threads
[pid 21122] read(16, "273311", 5)  = 5
[pid 21122] read(16, "35221022422334204Y24532n4222*B363K255I+246d=H23rS275?373333;O"..., 257) = 257
[pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory)
[pid 21122] read(12, "00/w0022C00t220021223", 16) = 16
[pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-wal", F_OK) = -1 ENOENT (No such file or directory)
[pid 21122] read(16, "273311", 5)  = 5
[pid 21122] read(16, "n376^10230>210O;[Q362}25334Q<N266242200233y|360023521630427324C"..., 257) = 257
[pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory)
[pid 21122] read(12, "00/w0022C00t220021223", 16) = 16
[pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-wal", F_OK) = -1 ENOENT (No such file or directory)
[pid 21122] read(16, "273311", 5)  = 5
[pid 21122] read(16, "331271ij257^R30627;33724'315'242fv_353DTt261352D246tK377250G"..., 257) = 257
[pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory)
[pid 21122] read(12, "00/w0022C00t220021223", 16) = 16
[pid 21122] access("/volume2/@cloudstation/@sync/syncfolder-db.sqlite-wal", F_OK) = -1 ENOENT (No such file or directory)

Je vous épargne les détails mais en continuant à creuser je me suis aperçu que la cause initiale était le client DSCloud de mon smartphone qui génère un traffic TCP avec le NAS (port 6690) toutes les 5 secondes (les "read" sur le FD 16 ci dessus). En mode nominal le traffic mesuré est de 262 octets (257+5) à chaque itération (au passage il y intérêt a configurer le client androïd en mode "synchro sur wifi uniquement" sinon bonjour le forfait data, ca fait quand même plus de 4MB/jour! ...). Des que je le met en "pause" tout se calme.

Mis à part le fait que c'est un poil gonflant d'entendre régulièrement cet accès disque, je me demande si à la longue ça ne peut pas avoir une incidence négative sur la durée de vie du disque (j'imagine que ça correspond à une lecture répétitive du même bloc).

Je n'ai pas activé l'hibernation pour maximiser la durée de vie de mes disques (de toutes façon je ne vois pas comment le NAS pourrait hiberner alors que le démon cloudstation se réveille toutes les 5 secondes) et donc je me dis ça serait un peu dommage que ce phénomène produise l'effet inverse.

Qui aurait un avis sur tous ces points? Le comportement de DS Cloud vous semble-t-il normal? (ne serait-il pas possible qu'il soit prévenu de façon asynchrone des changements nécessitant une synchro, ce fonctionnement par "polling" me semble un peu artisanal)

Modifié par CoolRaoul
0
StéphanH Rising Star

StéphanH

Posté(e)
Posté(e)

Etonnant ...

J'utilise CloudStation également.

Je ne me suis jamais posé ce genre de question, mais, sous iPad et iOs, j'ai l'impression que la synchro ne se déclenche que lorsque j'ouvre le client.

Ce n'est qu'une impression ...

Sous CloudStation, s'il y a un équipement connecté (ton Androïd), tu devrais le voir comme actif ?

Je viens de regarder sur le mien : j'ai trois iMachin sur lesquels DSCloud tourne, mais aucun n'est affiché comme connecté, alors qu'ils sont tous les trois en WiFi à l'instant où j'écris ce post.

0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e) (modifié)

J'utilise CloudStation également.

Je ne me suis jamais posé ce genre de question, mais, sous iPad et iOs, j'ai l'impression que la synchro ne se déclenche que lorsque j'ouvre le client.

Ce n'est qu'une impression ...

De mon coté il n'y a aucun doute, je peux également visualiser le traffic via tcpdump d'ailleurs et ça confirme mon analyse.

Sous CloudStation, s'il y a un équipement connecté (ton Androïd), tu devrais le voir comme actif ?

Bien entendu et ça me semble normal.

Je viens de regarder sur le mien : j'ai trois iMachin sur lesquels DSCloud tourne, mais aucun n'est affiché comme connecté, alors qu'ils sont tous les trois en WiFi à l'instant où j'écris ce post.

Étrange, moi je vois bien "en ligne".

Ça passe "hors ligne" des que je met l'appareil hors tension (power off) ou si je force le client DScloud en "pause" (immédiatement dans le 1er cas et avec un petit délai dans le deuxième )

Testé à l'instant sur tablette et sur smartphone.

Modifié par CoolRaoul
0
  • 2 semaines après...
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e)

Bien entendu j'ai, des le début, un ouvert un dossier au support

Voila qu'aujourd'hui je reçois une réponse qui, en gros, me demande de faire un reset usine de mon NAS parce que, d'apres le dump que je leur ai envoyé, j'aurait installé optware (ce qui en plus est faux: j'ai simplement utilisé la même architecture de mount "/volume1/@opt" -> "/opt" pour mes *propres* binaires développés avec la toolchain officielle, mais ca leur suffit pour faire cette déduction.

Ça commence vraiment à me gonfler: chaque fois que je soumet un problème au support, la réponse reçue est de réinitialiser mon NAS. Je trouve cette manière de botter en touche vraiment insupportable.

En outre, on distingue bien dans les traces tcpdump (que je leur ai pourtant fournies) que c'est le client DScloud Androïd qui est a initiative de cet échange de données toutes les 5 seconds

Pourquoi donc n'essaient-ils pas d'investiguer pas aussi coté Androïd?

Donc, je fais une petite requête aux membres du forum qui passerait dans ce sujet: serait-il possible a certains utilisateurs DScloud, d'exécuter la commande suivante en connexion shell root (ssh ou telnet) sur leur NAS à un moment ou leur client DScloud est connecté en wifi :

/usr/sbin/tcpdump port 6690

et me dire si eux aussi ils constatent des paquets échangés toutes les 5 secondes.

Merci d'avance.

0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e) (modifié)

Donc, je fais une petite requête aux membres du forum qui passerait dans ce sujet: serait-il possible a certains utilisateurs DScloud, d'exécuter la commande suivante en connexion shell root (ssh ou telnet) sur leur NAS à un moment ou leur client DScloud est connecté en wifi :

/usr/sbin/tcpdump port 6690
et me dire si eux aussi ils constatent des paquets échangés toutes les 5 secondes.

Bon, vu que ma requête ci dessus n'a pas eu l'air de déchaîner l'enthousiasme des foules, j'ai fais la manip avec le Syno d'un pote et, comme je m'y attendais, j'ai pu là aussi constater ces échanges entre le smartphone et le démon cloudstation toutes les 5 secondes.

J'espère que cette fois le support Synology va bien vouloir reconnaître que le défaut est du coté du client DScloud et pas spécifique à la configuration de mon NAS.

A suivre.

Modifié par CoolRaoul
0
vincent7778 Newbie

vincent7778

Posté(e)
Posté(e) (modifié)

Salut, j'ai essayé de reproduire ton test, mais je n'ai pas "tcpdump", c'est difficile à mettre en place ? Sinon est-ce que je ne peux pas contourner le problème en utilisant un analyseur de trame sur mon pc ?

PS : quand je leur ai également soumis un problème pour moi (video station ne scannait rien du tout et restait "en cours") il m'a été répondu que j'avais SABnzbd non supporté et donc ça venait de moi. Sauf que je leur avait bien dit que j'avais désinstaller tous (sauf video station) les paquets pour tester et j'avais le même résultat. A la maj suivante le problème s'est corrigé seul, alors crois moi, le mail de retour que je leur ai fait n'était pas sympa, ils avaient tord, mais pour limiter le boulot, il cherche chaque petite bête, et si il n'y a pas : faites reset ... sauf que tout le monde ne peut pas se permettre de se cogner des reset comme ça, parce qu'ils introduisent des bugs ... Je te comprends là dessus.

Modifié par vincent7778
0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e)

Salut, j'ai essayé de reproduire ton test, mais je n'ai pas "tcpdump", c'est difficile à mettre en place ? Sinon est-ce que je ne peux pas contourner le problème en utilisant un analyseur de trame sur mon pc ?

Au moins depuis la version 5 tcpdump est intégré à DSM (dans "/usr/sbin/") pourtant!

0
vincent7778 Newbie

vincent7778

Posté(e)
Posté(e) 

NAS> ls
adsl-connect    ietd            ntpdc           svcgssd
adsl-start      inetd           openvpn         syslog-ng
adsl-status     ipsec           pppd            tc
adsl-stop       iw              pppoe           tcpdump
chroot          mount.nfs       pppoe-relay     telnetd
crond           mountd          pptp            udhcpd
dhcprelay       nfsd            saslauthd       wpa_cli
exportfs        nfsstat         showmount       wpa_passphrase
idmapd          ntpd            sm-notify       wpa_supplicant
ietadm          ntpdate         statd           xl2tpd
NAS> tcpdump port 6690
tcpdump: SIOCGIFFLAGS: bonding_masters: No such device

Effectivement, je le vois, mais il m'aime pas :(

0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e) 

NAS> tcpdump port 6690
tcpdump: SIOCGIFFLAGS: bonding_masters: No such device
Effectivement, je le vois, mais il m'aime pas :(

Peut-être n'est-tu pas root

Autre possibilité, spécifier l'interface dans la commande.

un "netstat -i" va lister tes interfaces,

sélectionner celle avec l'ip du LAN ("eth0" pour moi)

et ensuite:

tcpdump -i eth0 port 6690
0
vincent7778 Newbie

vincent7778

Posté(e)
Posté(e) (modifié)

Je suis bien en root, mais effectivement, en précisant l'interface (je suis sur un 2413+) c'est mieux :D

Ceci t'aide (j'essaye aussi de comprendre, mais ne connaissant pas, je suis plus lent :P) ?

PS : en plus de mon client android, j'ai 3 autres client (NAS Syno) de connectés (je peux mettre les 3 NAS en pause temporairement si on peut y voir plus clair).

NAS> tcpdump -i eth0 port 6690
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:52:19.448171 IP ver27-1-88-172-36-114.fbx.proxad.net.54304 > NAS.6690: Flags [P.], seq 2366037926:2366038351, ack 1335636960, win 2003, options [nop,nop,TS val 26555434 ecr 1682834911], length 425
08:52:19.450107 IP NAS.6690 > ver27-1-88-172-36-114.fbx.proxad.net.54304: Flags [P.], seq 1:289, ack 425, win 661, options [nop,nop,TS val 1682840440 ecr 26555434], length 288
08:52:19.485269 IP ver27-1-88-172-36-114.fbx.proxad.net.54304 > NAS.6690: Flags [.], ack 289, win 2003, options [nop,nop,TS val 26555437 ecr 1682840440], length 0
08:52:21.486529 IP 192.168.1.1.47698 > NAS.6690: Flags [P.], seq 3647949811:3647949834, ack 1662612129, win 795, options [nop,nop,TS val 2488556 ecr 1682789625], length 23
08:52:21.486571 IP NAS.6690 > 192.168.1.1.47698: Flags [R], seq 1662612129, win 0, length 0
08:52:21.486711 IP 192.168.1.1.47698 > NAS.6690: Flags [F.], seq 23, ack 1, win 795, options [nop,nop,TS val 2488556 ecr 1682789625], length 0
08:52:21.486734 IP NAS.6690 > 192.168.1.1.47698: Flags [R], seq 1662612129, win 0, length 0
08:52:21.486882 IP 192.168.1.1.47698 > NAS.6690: Flags [R.], seq 24, ack 1, win 795, options [nop,nop,TS val 2488556 ecr 1682789625], length 0
08:52:21.487364 IP 192.168.1.1.47701 > NAS.6690: Flags , seq 3063569983, win 14600, options [mss 1460,sackOK,TS val 2488556 ecr 0,nop,wscale 6], length 0
08:52:21.487400 IP NAS.6690 > 192.168.1.1.47701: Flags [S.], seq 325440856, ack 3063569984, win 14480, options [mss 1460,sackOK,TS val 1682842478 ecr 2488556,nop,wscale 6], length 0
08:52:21.490418 IP 192.168.1.1.47701 > NAS.6690: Flags [.], ack 1, win 229, options [nop,nop,TS val 2488558 ecr 1682842478], length 0
08:52:21.504467 IP 192.168.1.1.47701 > NAS.6690: Flags [P.], seq 1:115, ack 1, win 229, options [nop,nop,TS val 2488559 ecr 1682842478], length 114
08:52:21.504505 IP NAS.6690 > 192.168.1.1.47701: Flags [.], ack 115, win 227, options [nop,nop,TS val 1682842495 ecr 2488559], length 0
08:52:21.505235 IP NAS.6690 > 192.168.1.1.47701: Flags [P.], seq 1:257, ack 115, win 227, options [nop,nop,TS val 1682842496 ecr 2488559], length 256
08:52:21.506589 IP 192.168.1.1.47701 > NAS.6690: Flags [.], ack 257, win 245, options [nop,nop,TS val 2488559 ecr 1682842496], length 0
08:52:21.520720 IP 192.168.1.1.47701 > NAS.6690: Flags [P.], seq 115:167, ack 257, win 245, options [nop,nop,TS val 2488561 ecr 1682842496], length 52
08:52:21.521054 IP NAS.6690 > 192.168.1.1.47701: Flags [P.], seq 257:1609, ack 167, win 227, options [nop,nop,TS val 1682842511 ecr 2488561], length 1352
08:52:21.558746 IP 192.168.1.1.47701 > NAS.6690: Flags [.], ack 1609, win 288, options [nop,nop,TS val 2488565 ecr 1682842511], length 0
08:52:21.592355 IP 192.168.1.1.47701 > NAS.6690: Flags [P.], seq 167:477, ack 1609, win 288, options [nop,nop,TS val 2488568 ecr 1682842511], length 310
08:52:21.632133 IP NAS.6690 > 192.168.1.1.47701: Flags [.], ack 477, win 243, options [nop,nop,TS val 1682842623 ecr 2488568], length 0
08:52:21.633035 IP NAS.6690 > 192.168.1.1.47701: Flags [P.], seq 1609:1652, ack 477, win 243, options [nop,nop,TS val 1682842623 ecr 2488568], length 43
08:52:21.644725 IP 192.168.1.1.47701 > NAS.6690: Flags [.], ack 1652, win 288, options [nop,nop,TS val 2488573 ecr 1682842623], length 0
08:52:21.686112 IP 192.168.1.1.47701 > NAS.6690: Flags [P.], seq 477:663, ack 1652, win 288, options [nop,nop,TS val 2488577 ecr 1682842623], length 186
08:52:21.686152 IP NAS.6690 > 192.168.1.1.47701: Flags [.], ack 663, win 260, options [nop,nop,TS val 1682842676 ecr 2488577], length 0
08:52:21.687241 IP NAS.6690 > 192.168.1.1.47701: Flags [P.], seq 1652:1921, ack 663, win 260, options [nop,nop,TS val 1682842678 ecr 2488577], length 269
08:52:21.689481 IP 192.168.1.1.47701 > NAS.6690: Flags [.], ack 1921, win 330, options [nop,nop,TS val 2488578 ecr 1682842678], length 0
08:52:21.701104 IP 192.168.1.1.47701 > NAS.6690: Flags [P.], seq 663:927, ack 1921, win 330, options [nop,nop,TS val 2488579 ecr 1682842678], length 264
08:52:21.702600 IP NAS.6690 > 192.168.1.1.47701: Flags [P.], seq 1921:2209, ack 927, win 277, options [nop,nop,TS val 1682842693 ecr 2488579], length 288
08:52:21.738847 IP 192.168.1.1.47701 > NAS.6690: Flags [.], ack 2209, win 372, options [nop,nop,TS val 2488583 ecr 1682842693], length 0
08:52:22.205801 IP 192.168.1.1.39203 > NAS.6690: Flags [P.], seq 947685607:947686034, ack 1040154958, win 83, options [nop,nop,TS val 4430738 ecr 1682838188], length 427
08:52:22.207440 IP NAS.6690 > 192.168.1.1.39203: Flags [P.], seq 1:289, ack 427, win 661, options [nop,nop,TS val 1682843198 ecr 4430738], length 288
08:52:22.207961 IP 192.168.1.1.39203 > NAS.6690: Flags [.], ack 289, win 83, options [nop,nop,TS val 4430738 ecr 1682843198], length 0
08:52:23.229412 IP org78-1-78-233-144-106.fbx.proxad.net.58027 > NAS.6690: Flags [P.], seq 3254828625:3254829050, ack 438079542, win 13394, options [nop,nop,TS val 239064596 ecr 1682833101], length 425
08:52:23.231077 IP NAS.6690 > org78-1-78-233-144-106.fbx.proxad.net.58027: Flags [P.], seq 1:289, ack 425, win 661, options [nop,nop,TS val 1682844221 ecr 239064596], length 288
08:52:23.278232 IP org78-1-78-233-144-106.fbx.proxad.net.58027 > NAS.6690: Flags [.], ack 289, win 13394, options [nop,nop,TS val 239064601 ecr 1682844221], length 0
08:52:24.987856 IP ver27-1-88-172-36-114.fbx.proxad.net.54304 > NAS.6690: Flags [P.], seq 425:850, ack 289, win 2003, options [nop,nop,TS val 26555988 ecr 1682840440], length 425
08:52:24.989500 IP NAS.6690 > ver27-1-88-172-36-114.fbx.proxad.net.54304: Flags [P.], seq 289:577, ack 850, win 661, options [nop,nop,TS val 1682845980 ecr 26555988], length 288
08:52:25.023546 IP ver27-1-88-172-36-114.fbx.proxad.net.54304 > NAS.6690: Flags [.], ack 577, win 2003, options [nop,nop,TS val 26555991 ecr 1682845980], length 0
^C
38 packets captured
40 packets received by filter
0 packets dropped by kernel
Modifié par vincent7778
0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e)

Je suis bien en root, mais effectivement, en précisant l'interface (je suis sur un 2413+) c'est mieux :D

Ceci t'aide (j'essaye aussi de comprendre, mais ne connaissant pas, je suis plus lent :P) ?

PS : en plus de mon client android, j'ai 3 autres client (NAS Syno) de connectés (je peux mettre les 3 NAS en pause temporairement si on peut y voir plus clair).

Ca serait mieux en effet, l'objectif étant de focaliser sur le client android. (on peut filtrer uniquement ce dernier si on connait son IP en ajoutant "and host <ip>" à la commande "tcpdump" également)

0
vincent7778 Newbie

vincent7778

Posté(e)
Posté(e) (modifié)

Voila, ça sera plus clair, (dans CloudStation j'ai bien juste le client Android "en ligne")

NAS> tcpdump -i eth0 port 6690
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:14:58.212908 IP 192.168.1.1.41582 > NAS.6690: Flags , seq 1091148190, win 14600, options [mss 1460,sackOK,TS val 4566339 ecr 0,nop,wscale 9], length 0
09:14:58.212957 IP NAS.6690 > 192.168.1.1.41582: Flags [S.], seq 1031723465, ack 1091148191, win 14480, options [mss 1460,sackOK,TS val 1684199203 ecr 4566339,nop,wscale 6], length 0
09:14:58.214157 IP 192.168.1.1.41582 > NAS.6690: Flags [.], ack 1, win 29, options [nop,nop,TS val 4566339 ecr 1684199203], length 0
09:14:58.214347 IP 192.168.1.1.41582 > NAS.6690: Flags [P.], seq 1:119, ack 1, win 29, options [nop,nop,TS val 4566339 ecr 1684199203], length 118
09:14:58.214384 IP NAS.6690 > 192.168.1.1.41582: Flags [.], ack 119, win 227, options [nop,nop,TS val 1684199205 ecr 4566339], length 0
09:14:58.215002 IP NAS.6690 > 192.168.1.1.41582: Flags [P.], seq 1:257, ack 119, win 227, options [nop,nop,TS val 1684199205 ecr 4566339], length 256
09:14:58.215557 IP 192.168.1.1.41582 > NAS.6690: Flags [.], ack 257, win 31, options [nop,nop,TS val 4566339 ecr 1684199205], length 0
09:14:58.216599 IP 192.168.1.1.41582 > NAS.6690: Flags [P.], seq 119:171, ack 257, win 31, options [nop,nop,TS val 4566339 ecr 1684199205], length 52
09:14:58.216890 IP NAS.6690 > 192.168.1.1.41582: Flags [P.], seq 257:1609, ack 171, win 227, options [nop,nop,TS val 1684199207 ecr 4566339], length 1352
09:14:58.219590 IP 192.168.1.1.41582 > NAS.6690: Flags [P.], seq 171:481, ack 1609, win 37, options [nop,nop,TS val 4566339 ecr 1684199207], length 310
09:14:58.259132 IP NAS.6690 > 192.168.1.1.41582: Flags [.], ack 481, win 243, options [nop,nop,TS val 1684199250 ecr 4566339], length 0
09:14:58.260433 IP NAS.6690 > 192.168.1.1.41582: Flags [P.], seq 1609:1652, ack 481, win 243, options [nop,nop,TS val 1684199251 ecr 4566339], length 43
09:14:58.261851 IP 192.168.1.1.41582 > NAS.6690: Flags [P.], seq 481:679, ack 1652, win 37, options [nop,nop,TS val 4566344 ecr 1684199251], length 198
09:14:58.261887 IP NAS.6690 > 192.168.1.1.41582: Flags [.], ack 679, win 260, options [nop,nop,TS val 1684199252 ecr 4566344], length 0
09:14:58.283331 IP NAS.6690 > 192.168.1.1.41582: Flags [P.], seq 1652:2440, ack 679, win 260, options [nop,nop,TS val 1684199274 ecr 4566344], length 788
09:14:58.285434 IP 192.168.1.1.41582 > NAS.6690: Flags [P.], seq 679:702, ack 2440, win 42, options [nop,nop,TS val 4566346 ecr 1684199274], length 23
09:14:58.285974 IP 192.168.1.1.41582 > NAS.6690: Flags [F.], seq 702, ack 2440, win 42, options [nop,nop,TS val 4566346 ecr 1684199274], length 0
09:14:58.328129 IP NAS.6690 > 192.168.1.1.41582: Flags [.], ack 703, win 260, options [nop,nop,TS val 1684199319 ecr 4566346], length 0
09:14:59.284219 IP NAS.6690 > 192.168.1.1.41582: Flags [P.], seq 2440:2463, ack 703, win 260, options [nop,nop,TS val 1684200275 ecr 4566346], length 23
09:14:59.284382 IP NAS.6690 > 192.168.1.1.41582: Flags [F.], seq 2463, ack 703, win 260, options [nop,nop,TS val 1684200275 ecr 4566346], length 0
09:14:59.284412 IP NAS.6690 > 192.168.1.1.41582: Flags [R.], seq 2464, ack 703, win 260, options [nop,nop,TS val 1684200275 ecr 4566346], length 0
09:14:59.286505 IP 192.168.1.1.41582 > NAS.6690: Flags [R], seq 1091148893, win 0, length 0
09:14:59.286694 IP 192.168.1.1.41582 > NAS.6690: Flags [R], seq 1091148893, win 0, length 0
09:15:08.333407 IP 192.168.1.1.41583 > NAS.6690: Flags , seq 2257709204, win 14600, options [mss 1460,sackOK,TS val 4567351 ecr 0,nop,wscale 9], length 0
09:15:08.333462 IP NAS.6690 > 192.168.1.1.41583: Flags [S.], seq 4098319975, ack 2257709205, win 14480, options [mss 1460,sackOK,TS val 1684209324 ecr 4567351,nop,wscale 6], length 0
09:15:08.334621 IP 192.168.1.1.41583 > NAS.6690: Flags [.], ack 1, win 29, options [nop,nop,TS val 4567351 ecr 1684209324], length 0
09:15:08.334800 IP 192.168.1.1.41583 > NAS.6690: Flags [P.], seq 1:119, ack 1, win 29, options [nop,nop,TS val 4567351 ecr 1684209324], length 118
09:15:08.334850 IP NAS.6690 > 192.168.1.1.41583: Flags [.], ack 119, win 227, options [nop,nop,TS val 1684209325 ecr 4567351], length 0
09:15:08.335505 IP NAS.6690 > 192.168.1.1.41583: Flags [P.], seq 1:257, ack 119, win 227, options [nop,nop,TS val 1684209326 ecr 4567351], length 256
09:15:08.336027 IP 192.168.1.1.41583 > NAS.6690: Flags [.], ack 257, win 31, options [nop,nop,TS val 4567351 ecr 1684209326], length 0
09:15:08.337127 IP 192.168.1.1.41583 > NAS.6690: Flags [P.], seq 119:171, ack 257, win 31, options [nop,nop,TS val 4567351 ecr 1684209326], length 52
09:15:08.337416 IP NAS.6690 > 192.168.1.1.41583: Flags [P.], seq 257:1609, ack 171, win 227, options [nop,nop,TS val 1684209328 ecr 4567351], length 1352
09:15:08.340195 IP 192.168.1.1.41583 > NAS.6690: Flags [P.], seq 171:481, ack 1609, win 37, options [nop,nop,TS val 4567351 ecr 1684209328], length 310
09:15:08.380132 IP NAS.6690 > 192.168.1.1.41583: Flags [.], ack 481, win 243, options [nop,nop,TS val 1684209371 ecr 4567351], length 0
09:15:08.380908 IP NAS.6690 > 192.168.1.1.41583: Flags [P.], seq 1609:1652, ack 481, win 243, options [nop,nop,TS val 1684209371 ecr 4567351], length 43
09:15:08.382069 IP 192.168.1.1.41583 > NAS.6690: Flags [P.], seq 481:679, ack 1652, win 37, options [nop,nop,TS val 4567356 ecr 1684209371], length 198
09:15:08.382118 IP NAS.6690 > 192.168.1.1.41583: Flags [.], ack 679, win 260, options [nop,nop,TS val 1684209372 ecr 4567356], length 0
09:15:08.402803 IP NAS.6690 > 192.168.1.1.41583: Flags [P.], seq 1652:2440, ack 679, win 260, options [nop,nop,TS val 1684209393 ecr 4567356], length 788
09:15:08.404949 IP 192.168.1.1.41583 > NAS.6690: Flags [P.], seq 679:702, ack 2440, win 42, options [nop,nop,TS val 4567358 ecr 1684209393], length 23
09:15:08.405465 IP 192.168.1.1.41583 > NAS.6690: Flags [F.], seq 702, ack 2440, win 42, options [nop,nop,TS val 4567358 ecr 1684209393], length 0
09:15:08.447126 IP NAS.6690 > 192.168.1.1.41583: Flags [.], ack 703, win 260, options [nop,nop,TS val 1684209438 ecr 4567358], length 0
09:15:09.404216 IP NAS.6690 > 192.168.1.1.41583: Flags [P.], seq 2440:2463, ack 703, win 260, options [nop,nop,TS val 1684210395 ecr 4567358], length 23
09:15:09.404372 IP NAS.6690 > 192.168.1.1.41583: Flags [F.], seq 2463, ack 703, win 260, options [nop,nop,TS val 1684210395 ecr 4567358], length 0
09:15:09.404401 IP NAS.6690 > 192.168.1.1.41583: Flags [R.], seq 2464, ack 703, win 260, options [nop,nop,TS val 1684210395 ecr 4567358], length 0
09:15:09.406450 IP 192.168.1.1.41583 > NAS.6690: Flags [R], seq 2257709907, win 0, length 0
09:15:09.406731 IP 192.168.1.1.41583 > NAS.6690: Flags [R], seq 2257709907, win 0, length 0
09:15:18.452640 IP 192.168.1.1.41584 > NAS.6690: Flags , seq 4099841348, win 14600, options [mss 1460,sackOK,TS val 4568363 ecr 0,nop,wscale 9], length 0
09:15:18.452692 IP NAS.6690 > 192.168.1.1.41584: Flags [S.], seq 1053825167, ack 4099841349, win 14480, options [mss 1460,sackOK,TS val 1684219443 ecr 4568363,nop,wscale 6], length 0
09:15:18.453873 IP 192.168.1.1.41584 > NAS.6690: Flags [.], ack 1, win 29, options [nop,nop,TS val 4568363 ecr 1684219443], length 0
09:15:18.454051 IP 192.168.1.1.41584 > NAS.6690: Flags [P.], seq 1:119, ack 1, win 29, options [nop,nop,TS val 4568363 ecr 1684219443], length 118
09:15:18.454094 IP NAS.6690 > 192.168.1.1.41584: Flags [.], ack 119, win 227, options [nop,nop,TS val 1684219444 ecr 4568363], length 0
09:15:18.454888 IP NAS.6690 > 192.168.1.1.41584: Flags [P.], seq 1:257, ack 119, win 227, options [nop,nop,TS val 1684219445 ecr 4568363], length 256
09:15:18.455342 IP 192.168.1.1.41584 > NAS.6690: Flags [.], ack 257, win 31, options [nop,nop,TS val 4568363 ecr 1684219445], length 0
09:15:18.456490 IP 192.168.1.1.41584 > NAS.6690: Flags [P.], seq 119:171, ack 257, win 31, options [nop,nop,TS val 4568363 ecr 1684219445], length 52
09:15:18.456777 IP NAS.6690 > 192.168.1.1.41584: Flags [P.], seq 257:1609, ack 171, win 227, options [nop,nop,TS val 1684219447 ecr 4568363], length 1352
09:15:18.459582 IP 192.168.1.1.41584 > NAS.6690: Flags [P.], seq 171:481, ack 1609, win 37, options [nop,nop,TS val 4568363 ecr 1684219447], length 310
09:15:18.499139 IP NAS.6690 > 192.168.1.1.41584: Flags [.], ack 481, win 243, options [nop,nop,TS val 1684219490 ecr 4568363], length 0
09:15:18.502022 IP NAS.6690 > 192.168.1.1.41584: Flags [P.], seq 1609:1652, ack 481, win 243, options [nop,nop,TS val 1684219492 ecr 4568363], length 43
09:15:18.503292 IP 192.168.1.1.41584 > NAS.6690: Flags [P.], seq 481:679, ack 1652, win 37, options [nop,nop,TS val 4568368 ecr 1684219492], length 198
09:15:18.503324 IP NAS.6690 > 192.168.1.1.41584: Flags [.], ack 679, win 260, options [nop,nop,TS val 1684219494 ecr 4568368], length 0
09:15:18.524968 IP NAS.6690 > 192.168.1.1.41584: Flags [P.], seq 1652:2440, ack 679, win 260, options [nop,nop,TS val 1684219515 ecr 4568368], length 788
09:15:18.527239 IP 192.168.1.1.41584 > NAS.6690: Flags [P.], seq 679:702, ack 2440, win 42, options [nop,nop,TS val 4568370 ecr 1684219515], length 23
09:15:18.527718 IP 192.168.1.1.41584 > NAS.6690: Flags [F.], seq 702, ack 2440, win 42, options [nop,nop,TS val 4568370 ecr 1684219515], length 0
09:15:18.570131 IP NAS.6690 > 192.168.1.1.41584: Flags [.], ack 703, win 260, options [nop,nop,TS val 1684219561 ecr 4568370], length 0
09:15:19.526220 IP NAS.6690 > 192.168.1.1.41584: Flags [P.], seq 2440:2463, ack 703, win 260, options [nop,nop,TS val 1684220517 ecr 4568370], length 23
09:15:19.526383 IP NAS.6690 > 192.168.1.1.41584: Flags [F.], seq 2463, ack 703, win 260, options [nop,nop,TS val 1684220517 ecr 4568370], length 0
09:15:19.526413 IP NAS.6690 > 192.168.1.1.41584: Flags [R.], seq 2464, ack 703, win 260, options [nop,nop,TS val 1684220517 ecr 4568370], length 0
09:15:19.528376 IP 192.168.1.1.41584 > NAS.6690: Flags [R], seq 4099842051, win 0, length 0
09:15:19.528605 IP 192.168.1.1.41584 > NAS.6690: Flags [R], seq 4099842051, win 0, length 0
^C
69 packets captured
69 packets received by filter
0 packets dropped by kernel

On dirait que je suis plus dans les 10 sec moi, mais ça pose le même genre de problème.

Modifié par vincent7778
0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e) (modifié)

Tiens étonnant, tu as un traffic bien plus important (et régulier) que moi. Peut-être as-tu des synchro en cours.

De mon coté c'est *pile* toutes les 5 secondes, 3 paquets échangés (Phone -> NAS, NAS->phone, Phone -> NAS):

fserv> /usr/sbin/tcpdump -i eth0 -n port 6690 -c 9 | awk '{print $1,$3,$4,$5$(NF-1), $(NF)}'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
9 packets captured
9 packets received by filter
0 packets dropped by kernel
09:43:26.322265 92.158.61.207.34300 > 192.168.1.14.6690:length 262
09:43:26.325695 192.168.1.14.6690 > 92.158.61.207.34300:length 287
09:43:26.384535 92.158.61.207.34300 > 192.168.1.14.6690:length 0
09:43:31.559302 92.158.61.207.34300 > 192.168.1.14.6690:length 262
09:43:31.562443 192.168.1.14.6690 > 92.158.61.207.34300:length 287
09:43:31.622982 92.158.61.207.34300 > 192.168.1.14.6690:length 0
09:43:36.922400 92.158.61.207.34300 > 192.168.1.14.6690:length 262
09:43:36.925531 192.168.1.14.6690 > 92.158.61.207.34300:length 287
09:43:36.989821 92.158.61.207.34300 > 192.168.1.14.6690:length 0

Modifié par CoolRaoul
0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e) (modifié)

Pas de synchro (en tout cas les dossiers sont vides) et tout autre client est en pause (marqué "hors ligne").

Etrange alors.

En tout cas tu observes bien un trafic permanent (bien qu'avec un profil différent) même en l'absence de synchro. Ce que je considère comme anormal.

De toutes façon, te biles pas: maintenant que j'ai pu faire des des tests avec le NAS de mon pote qui m'ont permit de constater exactement le même comportement qu'avec le mien, j'espère que ça suffira pour faire entendre raison au support.

Modifié par CoolRaoul
0
  • 2 semaines après...
Geoff1330 Enthusiast

Geoff1330

Posté(e)
Posté(e)

Bonjour,

Je ne suis pas aussi expérimenter que vous.

J'ai constaté le même problème:

Mes disques sont utiliser à 80% tout le temps quand CloudStation est actif.

par contre, je n'utilise qu'un client windows...

C'est assez embêtent parce que mon vieux DS411J deviens tout de suite moins réactif à cause de ca.

Y aurait-il une solution?

Merci

Geoff

0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e)

J'ai constaté le même problème:

Mes disques sont utiliser à 80% tout le temps quand CloudStation est actif.

Vu la description que tu donnes ça ne peut pas être le *même* problème: dans le cas que je décrit, il s'agit d'acces à intervalles réguliers pour lire quelques octets à peine, on est très loin d'un taux d'utilisation de 80% en continu.

0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e)

Retour du support syno sur le sujet:

"the design is that every 5 seconds it would be polling once to the server to ensure if there are any new files modifications.
Thus it's normal behavior in that case."

<_<

Conclusion: appli codée avec les pieds.

Sachant que chacun des clients maintient une connexion *permanente* avec le serveur (j'ai vérifié), il serait quand même plus efficace que ce soit ce dernier, lorsqu'il détecte une modification, qui prenne l'initiative d'en informer ses clients par le biais du lien réseau pré-existant..

C'est du niveau première année de dev d'applications client-serveur je trouve.

Décu par Syno sur le coup.

0
bud77 Newbie

bud77

Posté(e)
Posté(e)

Retour du support syno sur le sujet:

"the design is that every 5 seconds it would be polling once to the server to ensure if there are any new files modifications.

Thus it's normal behavior in that case."

<_<

Conclusion: appli codée avec les pieds.

Sachant que chacun des clients maintient une connexion *permanente* avec le serveur (j'ai vérifié), il serait quand même plus efficace que ce soit ce dernier, lorsqu'il détecte une modification, qui prenne l'initiative d'en informer ses clients par le biais du lien réseau pré-existant..

C'est du niveau première année de dev d'applications client-serveur je trouve.

Décu par Syno sur le coup.

Vive l'autonomie des périphériques du coup ...

0
CoolRaoul Community Regular

CoolRaoul

Posté(e)
  • Auteur
Posté(e) (modifié)

Vive l'autonomie des périphériques du coup ...

J'avais un autre ticket au support dans le même préimètre sur le fait que dscloud écrive dans la mémoire interne du téléphone plusieurs megas de logs par jours (pas top pour la durée de vie de la mémoire flash) et la réponse vient de tomber:

According to our developer, this behavior is normal. Current design is that it will record diagnostic log.

(But not to a very detailed extent. Just some basic INFO to log any abnormalities

La encore c'est n'importe quoi pour le "not to a very detailed extent" : l'énorme majorité des messages dans les fichiers logs dscloud dur le smartphone sont taggés "[DEBUG]" et pas "[iNFO]" et il y en a jusqu'a plusieurs dizaines par seconde!

(NB:Il y a bien un fichier nommé "cloud-daemon.debug" semblant contenir des parametres de verbosité des logs DScloud et que j'avais essayé de bidouiller mais DScloud le réécrit systématiquement.)

La mauvaise foi du support me gonfle par moment.

Je crois que DScloud et moi, c'est une histoire terminée.

Modifié par CoolRaoul
0
bud77 Newbie

bud77

Posté(e)
Posté(e)

+1 aussi

Je dois avouer qu'au niveau développement mobile, ils doivent revoir la copie

(Après, si tu dois *vraiment* te servir de l'appli, tu peux toujours la décompiler et faire quelques modifs :D)

0

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
 Partager
Aller sur la liste des sujets
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.